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. > > 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? > 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 -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
