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