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

--===============3562959778603712644==
Content-Type: multipart/alternative; boundary="0000000000008c28c805921ea39e"

--0000000000008c28c805921ea39e
Content-Type: text/plain; charset="UTF-8"

On Fri, Sep 6, 2019 at 3:02 AM Adam Williamson <[email protected]>
wrote:

> On Tue, 2019-09-03 at 13:38 -0400, David Lehman wrote:
> > On Fri, 2019-08-23 at 12:16 -0700, Adam Williamson wrote:
> > > Hey folks!
> >
> > Hi Adam! Thanks for bringing this up again.
> >
> > > 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 like option 3 most. The current criteria have always seemed, to me,
> > too vague. I'd be happy to help hash out the details if/when it
> > happens.
>
> Thanks for the offer.
>
> So aside from the 'fun' of drafting very specific rules, my concern
> with #3 is we would then potentially be shipping an installer that
> presents things as roughly equal choices which are not in fact equally
> supported. You can pick 'btrfs' or 'ext4' from the dropdown...but one
> of those we commit to making sure is working, one of them we don't.
>
> That to me is concerning; in this scenario I'd prefer we indicate
> somehow, somewhere, that all the choices are not equally guaranteed to
> be reliable. WDYT?
>

Hi Adam,

I think that the best option is to add a new storage validation check that
will report a warning if a user wants to use a file system that is not
recommended by the installed product. The list of recommended file systems
would be provided by the Anaconda configuration files, so products and
variants could override it.

We already show warnings with recommendations, for example for too small
root partition or missing swap. The storage validation checks are run for
every type of partitioning, results are logged and warnings have to be
waved by the user in the interactive mode.

Vendy


> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
>
> _______________________________________________
> Anaconda-devel-list mailing list
> [email protected]
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
>

--0000000000008c28c805921ea39e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Fri, Sep 6, 2019 at 3:02 AM Adam Williamson &lt;<a href=
=3D"mailto:[email protected]">[email protected]</a>&gt; w=
rote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">On Tue, 2019-09-03 at 13:38 -0400, David Lehman wrote:<br>
&gt; On Fri, 2019-08-23 at 12:16 -0700, Adam Williamson wrote:<br>
&gt; &gt; Hey folks!<br>
&gt; <br>
&gt; Hi Adam! Thanks for bringing this up again.<br>
&gt; <br>
&gt; &gt; So...what should we do? Here are the options as I see &#39;em:<br=
>
&gt; &gt; <br>
&gt; &gt; 1. Keep supporting btrfs<br>
&gt; &gt; 2. Just modify the criterion with a btrfs exception, even if it&#=
39;s<br>
&gt; &gt; weird<br>
&gt; &gt; 3. Rewrite the criterion entirely<br>
&gt; &gt; 4. Keep btrfs support in the installer (and blivet-gui) but hide =
it<br>
&gt; &gt; as<br>
&gt; &gt; we used to - require a special boot argument for it to be visible=
<br>
&gt; &gt; 5. Drop btrfs support from the installer<br>
&gt; <br>
&gt; I like option 3 most. The current criteria have always seemed, to me,<=
br>
&gt; too vague. I&#39;d be happy to help hash out the details if/when it<br=
>
&gt; happens.<br>
<br>
Thanks for the offer.<br>
<br>
So aside from the &#39;fun&#39; of drafting very specific rules, my concern=
<br>
with #3 is we would then potentially be shipping an installer that<br>
presents things as roughly equal choices which are not in fact equally<br>
supported. You can pick &#39;btrfs&#39; or &#39;ext4&#39; from the dropdown=
...but one<br>
of those we commit to making sure is working, one of them we don&#39;t.<br>
<br>
That to me is concerning; in this scenario I&#39;d prefer we indicate<br>
somehow, somewhere, that all the choices are not equally guaranteed to<br>
be reliable. WDYT?<br></blockquote><div><br></div><div></div><div>Hi Adam,<=
/div><div><br></div><div>I think that the best option is to add a new stora=
ge validation check that will report a warning if a user wants to use a fil=
e system that is not recommended by the installed product. The list of reco=
mmended file systems would be provided by the Anaconda configuration files,=
 so products and variants could override it.</div><div><br></div><div>We al=
ready show warnings with recommendations, for example for too small root pa=
rtition or missing swap. The storage validation checks are run for every ty=
pe of partitioning, results are logged and warnings have to be waved by the=
 user in the interactive mode.</div><div><br></div><div>Vendy<br></div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-- <br>
Adam Williamson<br>
Fedora QA Community Monkey<br>
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net<br>
<a href=3D"http://www.happyassassin.net" rel=3D"noreferrer" target=3D"_blan=
k">http://www.happyassassin.net</a><br>
<br>
_______________________________________________<br>
Anaconda-devel-list mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">Anacond=
[email protected]</a><br>
<a href=3D"https://www.redhat.com/mailman/listinfo/anaconda-devel-list" rel=
=3D"noreferrer" target=3D"_blank">https://www.redhat.com/mailman/listinfo/a=
naconda-devel-list</a><br>
</blockquote></div></div>

--0000000000008c28c805921ea39e--


--===============3562959778603712644==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Anaconda-devel-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
--===============3562959778603712644==--