Partitioning criteria revision proposal

[David Lehman]

On Thu, 2012-10-25 at 16:47 -0700, Adam Williamson wrote:
> On Thu, 2012-10-25 at 18:22 -0500, David Lehman wrote:
> > On Tue, 2012-10-16 at 17:55 -0700, Adam Williamson wrote:
> > > On Wed, 2012-10-10 at 22:31 -0700, Adam Williamson wrote:
> > > > Hey, folks. So it became clear over the course of the last few blocker
> > > > reviews that the new partitioning criteria need a bit of refinement.
> > > > Here is my proposal for altering them.
> > > 
> > > So...aside from the specific discussion of my proposals, I was thinking
> > > some more in general about the design of the partitioning criteria, and
> > > I'm starting to wonder if we're maybe getting too ambitious in terms of
> > > what we require at Beta, especially compared to previous releases.
> > > 
> > > So if we go back again and look at how things were before, here is what
> > > we required:
> > > 
> > > At Alpha, the offered autopart mechanisms except for 'shrink' had to
> > > work: this covered wiping entire disks and autoparting into the empty
> > > space, wiping only Linux partitions (preserving Windows ones) and
> > > autoparting into the empty space, and autoparting into existing empty
> > > space. It also covered LVM and non-LVM, and encrypted and non-encrypted,
> > > variations on autopart, as these were offered on the autopart screen. We
> > > did not require anything from custom partitioning.
> > > 
> > > At Beta, we added a requirement that the installer be able to install to
> > > hardware and BIOS RAID arrays, and create and install to software RAID
> > > arrays (softRAID is a function of custom partitioning; this is the only
> > > thing we required to work in custom partitioning at Beta).
> > > 
> > > At Final, we basically required any viable partitioning scheme to work
> > > (by implication and policy, custom partitioning issues were all
> > > considered Final blockers, aside from softRAID).
> > > 
> > > So, we only required softRAID functionality from the custom partitioning
> > > bit at Beta; all other requirements for custom partitioning were Final.
> > 
> > I am struggling to imagine the reasoning for requiring only md raid
> > here.
> 
> Well it wasn't quite drawn up that way. It was more 'oh, hey, RAID has
> to work at Beta'. So fwraid, HW raid and sw raid are all supposed to
> work at Beta...but the only one of those that actually relies on custom
> partitioning is sw raid. You can only create an sw raid layout through
> custom partitioning. But you configure fw raid and hw raid through your
> BIOS or RAID controller BIOS or whatever. You can install to fw raid or
> hw raid without entering custom partitioning, both in oldUI and newUI.
> So _in practice_, we wound up in this odd situation where we required
> precisely one thing from custom partitioning at Beta - SW raid.

HW and FW RAID make fine sense to me. SW RAID shouldn't be lumped with
them for this purpose.

> 
> > > So I'd be interested in general opinions about whether we should go down
> > > the path of requiring quite a bit of reliability from custom
> > > partitioning at Beta stage, or whether we should perhaps dial that down
> > > a bit, and only really require extensive functionality from custom
> > > partitioning at Final stage, as we did for F17 and earlier. I'd
> > > especially be interested in what the anaconda team thinks, so could you
> > > folks chip in?
> > 
> > I'm inclined to say we should have some requirements for custom
> > partitioning functionality in the beta. It just so happens that there
> > isn't much custom storage functionality in the current anaconda that
> > isn't expected to work at least reasonably well, so that makes it a bit
> > easier this time around.
> 
> Thanks for this feedback. We can certainly go down the road of requiring
> functionality from custom part at Beta. The other point to ponder might
> be that we could require things to be _present and testable_ in custom
> partitioning, without necessarily requiring them to work 100%. Do you
> think that might be a useful way to look at things?

That sounds appropriate for beta.

> 
> > Here's what I think makes some sense as beta criteria for custom
> > storage:
> > 
> > - create new devices
> > - remove devices
> > - assign mountpoints to existing filesystems on existing
> >   devices as appropriate (ie: not for the root filesystem)
> > - reformat existing devices and assign mountpoints as
> >   appropriate
> > - run autopart from within custom, results subject to disk layout
> > 
> > This may be too broad. Perhaps we should define a set of common setups
> > for mdraid, btrfs, and lvm to avoid committing to support for every
> > imaginable permutation of each. This would apply to both handling of
> > pre-existing setups and what the installer can create. Examples:
> > 
> > mdraid: un-partitioned raid0, raid1, raid10 with partition members
> >         across two or more disks with encryption on top of the md
> >         layer
> > 
> > lvm: un-partitioned non-mirrored, non-striped lvm with partition
> >      pvs and encryption on top of the lv layer
> > 
> > btrfs: single, raid0, raid1 on across one or more partitions (two or
> >        more for raid0, raid1) with encryption underneath the btrfs
> >        layer
> > 
> > Some things I think should not be required for beta:
> > 
> > - broken/incomplete anything: lvm, md, fwraid, whatever
> > 
> > I'll stop there for the time being.
> 
> Thanks. This looks broadly like the direction we were moving in with
> this thread _before_ I decided to raise the question of whether we
> really need to require stuff from custom part. So perhaps we can just go
> back to driving in that direction, if you're happy with it.
> -- 
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
> http://www.happyassassin.net
>