12:19 p.m.
It seems there are some issues with the current Spins approval process,
but to workaround I've been asked to contact each of your lists to get
acks for approval to keep the ball rolling.
The spins feature page in question is located at:
https://fedoraproject.org/wiki/Ovirt_Node_Spin
For the test plan we are awaiting an upstream commit to virt-manager to
add in a tui version of virt-manager. We plan to showcase that in the
spin as well. This means the test plan will be updated from its current
state. (updated tentatively today)
For the artwork we have a boot splash screen in the unofficial spins
that we release ourselves on new builds, in the case of a spin this was
an item we are not allowed to change. We'll also be providing
screenshots of the new virt-manager-tui and standalone mode installation.
If you have any questions please contact me or apevec(a)redhat.com
Thanks,
Joey
12:27 p.m.
On Wed, Jul 13, 2011 at 13:19:52 -0400,
Joey Boggs <jboggs(a)redhat.com> wrote:
It seems there are some issues with the current Spins approval
process, but to workaround I've been asked to contact each of your
lists to get acks for approval to keep the ball rolling.
The spins feature page in question is located at:
https://fedoraproject.org/wiki/Ovirt_Node_Spin
On a related note, I made it clear that oVirt, Robitics and Scientific
Spins all had wiki pages and requested producing spins in some form
for F16, by adding entries for them on the spin releases page for F16.
https://fedoraproject.org/wiki/Releases/16/Spins
12:31 p.m.
I don't have any say in the process but I would like to comment that I
am starting to review oVirt for my own use and strongly support a well
thought-out spin for oVirt Node.
Cheers,
Christian Bryant | Los Angeles, CA
http://christianabryant.fedorapeople.com/
4096R/418C1BBA 39B5 C0D0 D57F 5FC9 11C8 7A01 8B2F 0A9F 418C 1BBA
----- Message from jboggs(a)redhat.com ---------
Date: Wed, 13 Jul 2011 13:19:52 -0400
From: Joey Boggs <jboggs(a)redhat.com>
Reply-To: The Spin Special Interest Group mailing list
<spins(a)lists.fedoraproject.org>
Subject: [Fedora-spins] oVirt Node Fedora 16 Spin
To: test(a)lists.fedoraproject.org
Cc: Bruno Wolff III <bruno(a)wolff.to>, jlaska(a)fedoraproject.org,
Alan Pevec <apevec(a)redhat.com>, design-team(a)lists.fedoraproject.org,
The Spin Special Interest Group mailing list
<spins(a)lists.fedoraproject.org>, duffy(a)fedoraproject.org, Perry Myers
<pmyers(a)redhat.com>, cwickert(a)fedoraproject.org
It seems there are some issues with the current Spins approval
process,
but to workaround I've been asked to contact each of your lists to get
acks for approval to keep the ball rolling.
The spins feature page in question is located at:
https://fedoraproject.org/wiki/Ovirt_Node_Spin
For the test plan we are awaiting an upstream commit to virt-manager to
add in a tui version of virt-manager. We plan to showcase that in the
spin as well. This means the test plan will be updated from its current
state. (updated tentatively today)
For the artwork we have a boot splash screen in the unofficial spins
that we release ourselves on new builds, in the case of a spin this was
an item we are not allowed to change. We'll also be providing
screenshots of the new virt-manager-tui and standalone mode installation.
If you have any questions please contact me or apevec(a)redhat.com
Thanks,
Joey
_______________________________________________
spins mailing list
spins(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/spins
----- End message from jboggs(a)redhat.com -----
7:45 p.m.
On 07/13/2011 01:19 PM, Joey Boggs wrote:
It seems there are some issues with the current Spins approval
process, but to workaround I've been asked to contact each of your
lists to get acks for approval to keep the ball rolling.
The spins feature page in question is located at:
https://fedoraproject.org/wiki/Ovirt_Node_Spin
For the test plan we are awaiting an upstream commit to virt-manager
to add in a tui version of virt-manager. We plan to showcase that in
the spin as well. This means the test plan will be updated from its
current state. (updated tentatively today)
For the artwork we have a boot splash screen in the unofficial spins
that we release ourselves on new builds, in the case of a spin this
was an item we are not allowed to change. We'll also be providing
screenshots of the new virt-manager-tui and standalone mode installation.
If you have any questions please contact me or apevec(a)redhat.com
Thanks,
Joey
There seems to have been positive support for this spin so far, can we
get an official ACK to continue the process?
2:44 p.m.
On 07/14/2011 08:45 PM, Joey Boggs wrote:
On 07/13/2011 01:19 PM, Joey Boggs wrote:
> It seems there are some issues with the current Spins approval
> process, but to workaround I've been asked to contact each of your
> lists to get acks for approval to keep the ball rolling.
>
> The spins feature page in question is located at:
>
> https://fedoraproject.org/wiki/Ovirt_Node_Spin
>
> For the test plan we are awaiting an upstream commit to virt-manager
> to add in a tui version of virt-manager. We plan to showcase that in
> the spin as well. This means the test plan will be updated from its
> current state. (updated tentatively today)
>
> For the artwork we have a boot splash screen in the unofficial spins
> that we release ourselves on new builds, in the case of a spin this
> was an item we are not allowed to change. We'll also be providing
> screenshots of the new virt-manager-tui and standalone mode
> installation.
>
> If you have any questions please contact me or apevec(a)redhat.com
>
> Thanks,
> Joey
There seems to have been positive support for this spin so far, can we
get an official ACK to continue the process?
There seems to have been positive support for this spin so far, can we
get an official ACK from the Spins SIG to continue the process? Fedora
Design team has acked it and I'm just waiting on an offical ack from QA.
Once we have the three groups we can be accepted.
Thanks,
Joey
7:15 a.m.
On Tue, Jul 19, 2011 at 15:44:56 -0400,
Joey Boggs <jboggs(a)redhat.com> wrote:
There seems to have been positive support for this spin so far, can we
get an official ACK from the Spins SIG to continue the process? Fedora
Design team has acked it and I'm just waiting on an offical ack from QA.
Once we have the three groups we can be accepted.
I looked briefly at the ks file for the ovirt spin and it is a lot different
then the live images included in the past. Typically spins SIG only
reviewed live spins, which ovirt doesn't appear to be.
I think it might be better to consider this spin as outside the scope
of Spins SIG, as we would need to rewrite policy to be able to cover
ovirt, and I don't think that is going to happen in a timely fashion.
8:16 a.m.
On 07/26/2011 08:15 AM, Bruno Wolff III wrote:
On Tue, Jul 19, 2011 at 15:44:56 -0400,
Joey Boggs<jboggs(a)redhat.com> wrote:
> There seems to have been positive support for this spin so far, can we
> get an official ACK from the Spins SIG to continue the process? Fedora
> Design team has acked it and I'm just waiting on an offical ack from QA.
> Once we have the three groups we can be accepted.
I looked briefly at the ks file for the ovirt spin and it is a lot different
then the live images included in the past. Typically spins SIG only
reviewed live spins, which ovirt doesn't appear to be.
I think it might be better to consider this spin as outside the scope
of Spins SIG, as we would need to rewrite policy to be able to cover
ovirt, and I don't think that is going to happen in a timely fashion.
This specific spin can actually cover multiple use cases. It can boot
and run directly from the cd or be installed to a machine. Then add any
type ofstorage for libvirt and create vm's. It's original form was to
boot up and grab a configuration from a management server which gave out
storage and networking configurations as needed and provision templated
vm's from a web interface. That server framework was been released for
adoption as RHEV-M becomes open source it will replace it. When
installed to a machine and run it provides persistent storage for any
configuration files. The actual image itself stays in the same form as
it would in the iso, only storage for a volume group and grub
configuration are wrapped around it.
There may be multiple methods of running this spin but it will still run
from a cd/iso file just like any other spin.
12:40 p.m.
On 07/26/2011 09:16 AM, Joey Boggs wrote:
On 07/26/2011 08:15 AM, Bruno Wolff III wrote:
> On Tue, Jul 19, 2011 at 15:44:56 -0400,
> Joey Boggs<jboggs(a)redhat.com> wrote:
>> There seems to have been positive support for this spin so far, can we
>> get an official ACK from the Spins SIG to continue the process? Fedora
>> Design team has acked it and I'm just waiting on an offical ack from QA.
>> Once we have the three groups we can be accepted.
> I looked briefly at the ks file for the ovirt spin and it is a lot
> different
> then the live images included in the past. Typically spins SIG only
> reviewed live spins, which ovirt doesn't appear to be.
>
> I think it might be better to consider this spin as outside the scope
> of Spins SIG, as we would need to rewrite policy to be able to cover
> ovirt, and I don't think that is going to happen in a timely fashion.
This specific spin can actually cover multiple use cases. It can boot
and run directly from the cd or be installed to a machine. Then add any
type ofstorage for libvirt and create vm's. It's original form was to
boot up and grab a configuration from a management server which gave out
storage and networking configurations as needed and provision templated
vm's from a web interface. That server framework was been released for
adoption as RHEV-M becomes open source it will replace it. When
installed to a machine and run it provides persistent storage for any
configuration files. The actual image itself stays in the same form as
it would in the iso, only storage for a volume group and grub
configuration are wrapped around it.
There may be multiple methods of running this spin but it will still run
from a cd/iso file just like any other spin.
Right. oVirt Node is no different from any of the other Live spins in
that regard. It can both be run Live/stateless or installed to disk.
We just highlight the 'install to disk' presently functionality because
it maps to the current use case for RHEVH/RHEVM product that Red Hat has.
Other use cases may not require the 'install to disk' functionality.
For example, standalone usage via the virt-manager-tui or integration
with the Condor Cloud feature.
Besides, don't the other spins provide an option to install to hard disk?
Perry
9:30 a.m.
On Tue, Jul 26, 2011 at 13:40:00 -0400,
Perry Myers <pmyers(a)redhat.com> wrote:
Right. oVirt Node is no different from any of the other Live spins in
that regard. It can both be run Live/stateless or installed to disk.
We just highlight the 'install to disk' presently functionality because
it maps to the current use case for RHEVH/RHEVM product that Red Hat has.
Other use cases may not require the 'install to disk' functionality.
For example, standalone usage via the virt-manager-tui or integration
with the Condor Cloud feature.
Besides, don't the other spins provide an option to install to hard disk?
Yes they do.
The issue I am trying to avoid is that if we treat ovirt as a live spin,
it breaks some previously set rules, and there isn't a well functioning spins
SIG to make exceptions.
Also this is the third different base for a mini spin. There really should
be some work done to have nested levels of smallness so that work can
be reused. But this probably isn't going to happen any time soon, and may
not be a good reason to hold up a new spin.
10:11 a.m.
On 07/27/2011 10:30 AM, Bruno Wolff III wrote:
On Tue, Jul 26, 2011 at 13:40:00 -0400,
Perry Myers <pmyers(a)redhat.com> wrote:
>
> Right. oVirt Node is no different from any of the other Live spins in
> that regard. It can both be run Live/stateless or installed to disk.
> We just highlight the 'install to disk' presently functionality because
> it maps to the current use case for RHEVH/RHEVM product that Red Hat has.
>
> Other use cases may not require the 'install to disk' functionality.
> For example, standalone usage via the virt-manager-tui or integration
> with the Condor Cloud feature.
>
> Besides, don't the other spins provide an option to install to hard disk?
Yes they do.
The issue I am trying to avoid is that if we treat ovirt as a live spin,
it breaks some previously set rules, and there isn't a well functioning spins
SIG to make exceptions.
Can you point us to those rules? I have to admit ignorance in that I
wasn't aware there were specific rules about what constitutes a spin.
Also this is the third different base for a mini spin. There really
should
be some work done to have nested levels of smallness so that work can
be reused. But this probably isn't going to happen any time soon, and may
not be a good reason to hold up a new spin.
Agreed on having a consistent mini-spin. It seems to me that a Spin SIG
would be the right group to standardize on that mini-spin package set.
But to hold up acceptance of this particular spin due to the fact that
there isn't a properly functioning Spin SIG seems unfair.
Perry
10:21 a.m.
On 07/27/2011 11:11 AM, Perry Myers wrote:
On 07/27/2011 10:30 AM, Bruno Wolff III wrote:
> On Tue, Jul 26, 2011 at 13:40:00 -0400,
> Perry Myers <pmyers(a)redhat.com> wrote:
>>
>> Right. oVirt Node is no different from any of the other Live spins in
>> that regard. It can both be run Live/stateless or installed to disk.
>> We just highlight the 'install to disk' presently functionality because
>> it maps to the current use case for RHEVH/RHEVM product that Red Hat has.
>>
>> Other use cases may not require the 'install to disk' functionality.
>> For example, standalone usage via the virt-manager-tui or integration
>> with the Condor Cloud feature.
>>
>> Besides, don't the other spins provide an option to install to hard disk?
>
> Yes they do.
>
> The issue I am trying to avoid is that if we treat ovirt as a live spin,
> it breaks some previously set rules, and there isn't a well functioning spins
> SIG to make exceptions.
Can you point us to those rules? I have to admit ignorance in that I
wasn't aware there were specific rules about what constitutes a spin.
Alan pointed me properly to:
https://fedoraproject.org/wiki/Spins_SIG_Review_Checklist
My understanding is that we break rule 7 because we use a nochroot in
post to modify the boot menu. This seems like a minor infraction given
what we're using it for.
Aside from that, the other deviations include that we don't base
ourselves off of one of the kickstarts in rule 4, but that rule says
'may use any' not 'must use any'
So is the nochroot rule the reason for denying the spin, or are you
saying that the rules weren't specific enough and we're breaking the
spirit of what a spin should be, if not a specific rule?
> Also this is the third different base for a mini spin. There
really should
> be some work done to have nested levels of smallness so that work can
> be reused. But this probably isn't going to happen any time soon, and may
> not be a good reason to hold up a new spin.
Agreed on having a consistent mini-spin. It seems to me that a Spin SIG
would be the right group to standardize on that mini-spin package set.
But to hold up acceptance of this particular spin due to the fact that
there isn't a properly functioning Spin SIG seems unfair.
As an aside... the existing fedora-live-mini.ks isn't mini enough :)
Perhaps we can generalize our even more minimal kickstart to replace the
existing fedora-live-mini since we've shown a use case for an even
smaller set of packages for a livecd spin.
Perry
11:05 a.m.
On Wed, Jul 27, 2011 at 11:21:32 -0400,
Perry Myers <pmyers(a)redhat.com> wrote:
Aside from that, the other deviations include that we don't base
ourselves off of one of the kickstarts in rule 4, but that rule says
'may use any' not 'must use any'
So is the nochroot rule the reason for denying the spin, or are you
saying that the rules weren't specific enough and we're breaking the
spirit of what a spin should be, if not a specific rule?
An exception is supposed to be granted for any spins not basing off the
limited set of approved base spins. I am not denying the spin because I
don't see how spins SIG can deny anything when we aren't having regular
meetings of interested parties to discuss spins. However, for similar
reasons I am not approving it either.
> But to hold up acceptance of this particular spin due to the
fact that
> there isn't a properly functioning Spin SIG seems unfair.
I agree.
3:58 a.m.
Am Mittwoch, den 13.07.2011, 13:19 -0400 schrieb Joey Boggs:
It seems there are some issues with the current Spins approval
process,
but to workaround I've been asked to contact each of your lists to get
acks for approval to keep the ball rolling.
That is not really a workaround but a requirement of the process. You
are requested to introduce your spin on the mailing list.
Nevertheless I have to admit that the process is not really working well
because I don't get notified when somebody marks something 'Ready for
Wrangler' and I guess you didn't get notified of the spins review I did
back in September.
Please try to address my questions and give us an update. IIRC somebody
worked on the ks already and changed some things that I had mentioned,
so please give us a status update.
Thanks,
Regards,
Christoph
5:25 a.m.
Am Mittwoch, den 27.07.2011, 11:21 -0400 schrieb Perry Myers:
Alan pointed me properly to:
https://fedoraproject.org/wiki/Spins_SIG_Review_Checklist
My understanding is that we break rule 7 because we use a nochroot in
post to modify the boot menu. This seems like a minor infraction given
what we're using it for.
Currently the spin is violating more than just rule #7.
Rule 1: The spin doesn't have a wiki page approved by the spins
wrangler. That is of course my fault as I failed to look at earlier, but
I cannot approve it if whole paragraphs are missing. If this spin is
supposed to be available on spins.fedoraproject.org, it needs all the
sections about the website.
Rule 5: The spin uses a default block size of 1024 but the motivation is
not explained. Same goes for ext2 as filesystem, although this is not a
strict requirement AFAIK.
Rule 8: The spin touches/removes various configuration files but the
motivation is often unclear. Normally these changes should happen in the
livesys initscript so they are not permanent. If something is really
required for the installed node, please justify the changes more
elaborate in the KS.
Please address these issues either here on the mailing list or at
https://fedoraproject.org/wiki/Talk:Ovirt_Node_Spin and fix them in the
ks (if applicable).
Regards,
Christoph
7:23 a.m.
On 10/08/2011 06:25 AM, Christoph Wickert wrote:
Am Mittwoch, den 27.07.2011, 11:21 -0400 schrieb Perry Myers:
>
> Alan pointed me properly to:
> https://fedoraproject.org/wiki/Spins_SIG_Review_Checklist
>
> My understanding is that we break rule 7 because we use a nochroot in
> post to modify the boot menu. This seems like a minor infraction given
> what we're using it for.
Currently the spin is violating more than just rule #7.
Rule 1: The spin doesn't have a wiki page approved by the spins
wrangler. That is of course my fault as I failed to look at earlier, but
I cannot approve it if whole paragraphs are missing. If this spin is
supposed to be available on spins.fedoraproject.org, it needs all the
sections about the website.
Rule 5: The spin uses a default block size of 1024 but the motivation is
not explained. Same goes for ext2 as filesystem, although this is not a
strict requirement AFAIK.
Rule 8: The spin touches/removes various configuration files but the
motivation is often unclear. Normally these changes should happen in the
livesys initscript so they are not permanent. If something is really
required for the installed node, please justify the changes more
elaborate in the KS.
Please address these issues either here on the mailing list or at
https://fedoraproject.org/wiki/Talk:Ovirt_Node_Spin and fix them in the
ks (if applicable).
We've decided to remove the oVirt Node Spin from consideration as an
official Fedora Spin at this time. So we will not be addressing the
items above.
Regards,
Perry
4577
days inactive
4664
days old
14 comments
6 participants
participants (6)
-
Bruno Wolff III -
Christian Bryant -
Christoph Wickert -
Christoph Wickert -
Joey Boggs -
Perry Myers