Proposed Alpha criteria adjustments

[John Dulaney]

----------------------------------------
Subject: Re: Proposed Alpha criteria adjustments
From: jlaska at redhat.com
To: test at lists.fedoraproject.org
Date: Tue, 26 Jul 2011 07:56:38 -0400


>On Mon, 2011-07-25 at 21:12 -0700, Adam Williamson wrote:
>> On Fri, 2011-07-22 at 16:08 -0400, James Laska wrote:
>>
>> >         The installer must be able to complete an installation using the
>> >         entire disk, existing free space, or existing Linux partitions
>> >         methods, with or without encryption enabled
>> >
>> > I propose the following minor adjustment to the above criteria:
>> >
>> >         The installer must be able to complete an installation using the
>> >         entire disk, existing free space, or existing Linux partitions
>> >         methods, with or without encryption or LVM enabled.
>>
>> ack!

>Thanks, I've added the above criteria to the wiki

>https://fedoraproject.org/w/index.php?title=Fedora_16_Alpha_Release_Criteria&action=historysubmit&diff=247142&oldid=246263

>> > Any objections/corrections to the following Alpha criteria addition to
>> > cover the reboot/shutdown use case?
>> >
>> >         The systems' mechanisms for shutting down, logging out and
>> >         rebooting from a virtual console must work
>>
>> s,systems',system's,g

>Doh, thanks :)

>> I think we don't really need reboot to work; shut down and then turn
>> back on is a fine workaround at Alpha phase. If there was a bug in
>> rebooting, but shutting down worked, I'd probably not want that to be an
>> Alpha blocker. And since we're interested in the mechanics of shutting
>> down here, I'd like to be a bit more specific about what we mean by
>> 'work' (it's a less problematic concept when we're just talking about
>> *triggering* a shutdown). So, how about:
>>
>> It must be possible to trigger a system shutdown using standard console
>> commands, and the system must shut down in such a way that storage
>> volumes (e.g. simple partitions, LVs and PVs, RAID arrays) are taken
>> offline safely and the system's BIOS or EFI is correctly requested to
>> power down the system
>>
>> This covers the most important thing about shutdown (clean unmount) but
>> lets us not consider, say, one service not correctly going down to be a
>> blocker. It also gets around any case where we send a proper shutdown
>> trigger but there's a BIOS/EFI bug that causes the system not to
>> actually power off. (It's kind of debatable whether we actually care
>> about the system powering off, or if we just want to make sure storage
>> off line).

>I like it.  The only adjustment I might suggest would be to clarify the
>scope of services and storage considered.  You've already done so in
>your draft, but I wonder if we might still be exposed to unusual storage
>configurations.  Meaning, we have a still open issue regarding a system
>shutdown taking ages with LVM snapshots enabled.  We didn't consider
>that a blocker in F15 since snapshots were not enabled by default and
>considered atypical (local site configuration).  It still seems like a
>stretch to consider that an Alpha blocker.  Howabout refining it to
>limit the scope to Alpha criteria storage scenarios?  (meaning, not RAID
>or iSCSI or LVM snapshots etc...)...

        >On system's where storage and disk partitioning is consistent
        >with the Alpha release criteria, it must be possible to trigger
        >a system shutdown using standard console commands, and the
        >system must shut down in such a way that storage volumes are
        >taken offline safely and the system's BIOS or EFI is correctly
        >requested to power down the system

>A bit wordy ... but I think we're converging on similar scope.

>> There's a possibility we might want a more stringent requirement at
>> Final - say, standard services should power down properly - but I'm not
>> sure about that; we have a criterion for bugs that may cause data loss
>> or corruption, and I think that's the only really bad possible
>> consequence of improper service shutdown. But it's worth considering.

>Yeah, I could see a parallel criteria for shutdown that ensures all
>services installed+enabled by a default install exit cleanly.  For now
>though, I'm fine leaving that out until problems in that area surface.

>> We also need a test case for this, of course.

>Good point.  Unless anyone else wants a shot at it, I'll draft something
>up shortly and send to the list for review.

>Thanks for the feedback!
>James


I think that full system poweroff should be a criteria, because there are boxes
out there that cannot be completely powered off if the OS hangs on poweroff
without disconnecting power cable, removing battery, etc. (such as the laptop
I am typing this on).  I think that in a virtual machine this also could also
conceivably cause some issues.

Maybe I'm just rambling here?

John.