Partitioning criteria revision proposal

[David Lehman]

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.

> 
> Now with F18 Alpha 'autopart' was very very basic so we kind of got the
> idea that we'd have to require more custom part functionality to work at
> Alpha and Beta, and we've been working on that basis so far. But taking
> a step back and looking at it, the 'guided partitioning' flow in F18
> Beta is much more capable and nearly matches what autopart in F17
> offered. Without going into custom partitioning, you can autopart into
> empty space, or wipe any combination of existing partitions if you do
> not have sufficient free space. You can also encrypt the installation,
> now. There's only really two things missing:
> 
> a) you can't wipe or shrink partitions if you have sufficient free
> space, even if you want to (to provide *more* space for the install) -
> you have to use custom partitioning if you want to do this

This is unfortunate.

> 
> b) you can't do LVM without going into custom partitioning
> 
> but that's *all*. Everything else you could do with autopart in F17, you
> can do with 'guided partitioning' in F18. So I'm not sure the approach
> we're currently working on, of requiring extensive functionality from
> the custom partitioning tool at Beta time, is necessarily warranted. We
> could still decide we want certain things to work in custom partitioning
> at Beta time, but we don't really have to just in order to maintain the
> standards from previous releases, it would really constitute *raising*
> our standards.
> 
> 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.

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.