Proposed Alpha criteria adjustments

[James Laska]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/test/attachments/20110726/c11cd292/attachment-0001.bin