Proposed Alpha criteria adjustments

[James Laska]

On Tue, 2011-07-26 at 10:24 -0700, Adam Williamson wrote:
> On Tue, 2011-07-26 at 07:56 -0400, James Laska wrote:
> 
> > > 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...)...
> 
> The asymmetry there was intentional and I sort of like it; I think it's
> a bigger problem if we install to your type of storage then shut it down
> uncleanly than if we just don't install to it. But on the other hand,
> you could argue we can capture any really serious cases under the Final
> 'data corruption' criterion. So, I can see both sides on this.

To make sure I follow your concerns ...  by linking the storage
partitioning and console-based shutdown, you worry we're exposed to
other storage scenarios (RAID, iSCSI, FCoE etc...) where shutdown
wouldn't work and might leave the system in need of sck (or worse)?  

My rationale for making the link between shutdown and partitioning was
because it seemed odd to accept a RAID-related shutdown bug as an Alpha
blocker, but at the same time reject anything related to installing
RAID.

Would you feel comfortable if in addition to the proposed Alpha shutdown
criteria, we also update the existing Beta desktop-shutdown criteria to
include the "desktop, and console-based, mechanisms for shutting down a
system ..."?

> >         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.
> 
> Systems. =) No apostrophe at all now.

:)'s

Thanks,
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/3c8cea3c/attachment.bin