Partitioning criteria revision proposal

Adam Williamson awilliam at redhat.com
Thu Oct 11 05:31:35 UTC 2012


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. The current Beta partitioning
criteria are provided for reference:

current
-------

* The installer must be able to complete an installation using automatic
partitioning to a validly-formatted disk with sufficient empty space,
using the empty space and installing a bootloader but leaving the
pre-existing partitions and data untouched 

* The installer's custom partitioning mode must be capable of the
following:
** Creating, destroying and assigning mount points to partitions of any
specified size using most commonly-used filesystem types
** Creating encrypted partitions
** Rejecting obviously invalid operations without crashing 

* The installer must be able to create and install to software, hardware
or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot



Here are my proposed changes.

proposed
--------

* The installer must be able to complete an installation to a
validly-formatted disk with sufficient empty space, using the empty
space and installing a bootloader but leaving the pre-existing
partitions and data untouched, without using the custom partitioning
mode

* When there is not sufficient free space for installation, the
installer must allow the user to selectively remove existing partitions
without using the custom partitioning mode

* The installer's custom partitioning mode must be capable of the
following:
** Creating and, optionally, encrypting partitions of any specified size
using all offered device and filesystem types
** Assigning mount points to newly-created partitions
** Using an existing partition as the /home partition for the
installation without reformatting it
** Deleting any existing partition
** Rejecting obviously invalid operations without crashing



To break down the changes here...

Referring to 'automatic partitioning' was meant to talk about the 'help
you free up space' workflow, but it's a bit confusing as there's an
'automatic partitioning' option *within* custom part now. We could give
a name to the 'help you free up space' process and refer to that, but it
seemed easier just to say 'without using custom partitioning'. The basic
theory here is we're requiring certain functionality from the 'help you
free up space' workflow and also certain functionality from the 'custom
partitioning' workflow.

It seemed prudent to specifically require that removing partitions
selectively in the 'help you free up space' workflow must work at this
point. The previous Alpha and Beta criteria that we worked up didn't
exactly cover this: if the non-custom workflow could only completely
wipe disks or install into free space at Beta stage, it would have
passed under the old criteria.

It was pointed out that the 'Creating, destroying and assigning mount
points' wording had the effect of requiring re-use of existing
partitions at Beta to work, which wasn't really intended. The revision
attempts to be more clear about precisely what has to work at Beta:
really just 'creating a new partition layout' and 're-using /home',
which is a specific subset of 're-using existing partitions' that we
have reason to care about. This is a debatable point - we could
potentially require more in the way of existing partition re-use at
Beta. But I thought we'd start with just that case as a starting point.
If anyone has a convincing case for requiring more re-use cases (with or
without reformatting) to work at Beta, do speak up :)

We agreed at the blocker review meeting this morning that "most
commonly-used filesystem types" was really pretty vague and
unsatisfactory. The specific case we were considering was LVM. In the
end we agreed that, really, at Beta stage, anaconda ought to be capable
of dealing with any filesystem / device type it offers (the 'device
types' are LVM, RAID and btrfs). If a type isn't working it needs to be
either fixed or suppressed (as we did for the last couple of oldui
releases with btrfs - we suppressed it from the list as it wasn't
working). The intent here isn't to cover every possible bizarre
permutation anyone can come up with (the Final criterion does do that),
but more that just simply creating a partition in a pretty normal,
everyday way with any of the options offered shouldn't cause the
installer to fall over and die. Please, anaconda folks, if you think
this is too optimistic and you think we should exclude specific types or
limit the criterion to a specific subset of types, yell.

The specific RAID criterion seems to me to be pretty much subsumed in
the above proposals, so it can be dropped.

It's worth noting that we're still using the old 'The installer must be
able to create and install to any workable partition layout using any
file system offered in a default installer configuration, LVM, software,
hardware or BIOS RAID, or combination of the above' criterion for Final.
I think this is not entirely optimal; the scenario dcantrell proposed in
the 'criteria review' thread, for instance, would technically be covered
by this. But revising it would be very difficult, I think, because all
you can really do is either write a *giant* laundry list of use cases in
the 'custom partitioning should be capable of' format, which is ugly and
horribly non-scalable, or wave a white flag and say 'partitioning issues
are subjective and we'll just deal with them case-by-case'. Those are
the only options I can come up with, anyway. If anyone has a neat idea
for improving the final criterion, please do propose it, because I'm
damned if I can. :)

This is tricky stuff so I may well still be missing something, please do
take a close look at the proposal and point out any issues. thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net



More information about the test mailing list