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

Re: Discussion: what would not blocking on btrfs look like?



On Fri, Aug 23, 2019 at 9:17 PM Adam Williamson
<adamwill fedoraproject org> wrote:
>
> 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).

This thread has diverged wildly into a lot of delightful
invective-slinging at my team. In the interest of getting back to the
original topic at hand: I would be in support of three -- five.

Thanks for bringing this topic up, Adam, and for presenting this list
of options.

>
> 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
> _______________________________________________
> test mailing list -- test lists fedoraproject org
> To unsubscribe send an email to test-leave lists fedoraproject org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/test lists fedoraproject org



-- 
Samantha N. Bueno
Manager, Platform Engineering
Red Hat, Inc | Boston, MA


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