---------------------------------------- Subject: Re: Proposed Alpha criteria adjustments From: jlaska@xxxxxxxxxx To: test@xxxxxxxxxxxxxxxxxxxxxxx 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. -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
