[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Discussion: what would not blocking on btrfs look like?



Hey folks!

So, there was recently a Thing where btrfs installs were broken, and
this got accepted as a release blocker:

https://bugzilla.redhat.com/show_bug.cgi?id=1733388

The bug was fixed, so that's fine, but along the way, Laura said this:

"I'm strongly against anything with btrfs being a blocker. If that's in
the criteria I think we should see about removing btrfs simply because
we don't have the resources to actually deal with btrfs besides
reporting bugs upstream."

and Justin followed up with:

"Agreed, btrfs has been a gamble pretty much always. See previous
discussion around proposals to make btrfs default. Ext4 and xfs should
be the only release blocking."

So, that's the whole kernel team 'strongly against' blocking on btrfs.
Which means we should talk about not doing that any more!

This is a bit complicated, though, because of how the Final criteria
are phrased. Basic does not include btrfs at all, and Beta includes a
laundry list we can just remove btrfs from:

"When using both the installer-native and the blivet-gui-based custom
partitioning flow, the installer must be able to:

* Correctly interpret, and modify as described below, any disk with a
valid ms-dos or gpt disk label and partition table containing ext4
partitions, LVM and/or btrfs volumes, and/or software RAID arrays at
RAID levels 0, 1 and 5 containing ext4 partitions
* Create mount points backed by ext4 partitions, LVM volumes or btrfs
volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing
ext4 partitions
..."

so those two are easy. However, the Final criterion is not laundry
list-style. The relevant Final criterion is this:

"The installer must be able to create and install to any workable
partition layout using any file system and/or container format
combination offered in a default installer configuration."

with a somewhat apologetic explanatory footnote:

"Wait, what?
Yeah, we know. This is a huge catch-all criterion and it's subject to a
lot of on-the-fly interpretation. Broadly what it's 'meant to mean' is
that you should be able to do anything sane that the Installation
Destination spoke attempts to let you do, without the installer
exploding or failing. We are trying to write more specific criteria
covering this area, but it's not easy. Patches welcome, as the kids
say..."

so as the footnote says, the rule is basically "if the installer lets
you do it, it ought to work". It seems a bit awkward to craft an
exception for btrfs from that. I mean, technically it's easy:

"The installer must be able to create and install to any workable
partition layout using any file system and/or container format
combination offered in a default installer configuration, except
btrfs."

but that's odd. Why is btrfs, alone, an exception? It kinda goes
against the fundamental idea of the criterion: that we stand behind
everything the UI offers.

So...what should we do? Here are the options as I see 'em:

1. Keep supporting btrfs
2. Just modify the criterion with a btrfs exception, even if it's weird
3. Rewrite the criterion entirely
4. Keep btrfs support in the installer (and blivet-gui) but hide it as
we used to - require a special boot argument for it to be visible
5. Drop btrfs support from the installer

I'm bringing this to anaconda, kernel and test teams initially to kick
around; if we agree on an approach we should then probably loop in
devel@ for wider review, unless the choice is 1).

Thanks for any thoughts, folks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]