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@redhat.com
Thanks, Joey
On Wed, Jul 13, 2011 at 13:19:52 -0400, Joey Boggs jboggs@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:
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.
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@redhat.com --------- Date: Wed, 13 Jul 2011 13:19:52 -0400 From: Joey Boggs jboggs@redhat.com Reply-To: The Spin Special Interest Group mailing list spins@lists.fedoraproject.org Subject: [Fedora-spins] oVirt Node Fedora 16 Spin To: test@lists.fedoraproject.org Cc: Bruno Wolff III bruno@wolff.to, jlaska@fedoraproject.org, Alan Pevec apevec@redhat.com, design-team@lists.fedoraproject.org, The Spin Special Interest Group mailing list spins@lists.fedoraproject.org, duffy@fedoraproject.org, Perry Myers pmyers@redhat.com, cwickert@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@redhat.com
Thanks, Joey _______________________________________________ spins mailing list spins@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/spins
----- End message from jboggs@redhat.com -----
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@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?
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@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
On Tue, Jul 19, 2011 at 15:44:56 -0400, Joey Boggs jboggs@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.
On 07/26/2011 08:15 AM, Bruno Wolff III wrote:
On Tue, Jul 19, 2011 at 15:44:56 -0400, Joey Boggsjboggs@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.
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 Boggsjboggs@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
On Tue, Jul 26, 2011 at 13:40:00 -0400, Perry Myers pmyers@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.
On 07/27/2011 10:30 AM, Bruno Wolff III wrote:
On Tue, Jul 26, 2011 at 13:40:00 -0400, Perry Myers pmyers@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
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@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
On Wed, Jul 27, 2011 at 11:21:32 -0400, Perry Myers pmyers@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.
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
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
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
-
Bruno Wolff III -
Christian Bryant -
Christoph Wickert -
Christoph Wickert -
Joey Boggs -
Perry Myers