[Fedora-spins] oVirt Node Fedora 16 Spin

[Perry Myers]

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 at 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