Re: Discussion: what would not blocking on btrfs look like?
Vendula Poncova <[email protected]> Tue, 10 Sep 2019 17:57:11 +0200
| Newsgroups | gmane.linux.redhat.anaconda.devel |
|---|---|
| Message-ID | <CAAmygTTcC5Y6bQWwMqqj4QigHEaQ6MGokmyd9W9uggW12MdAUA@mail.gmail.com> |
--===============7745153007939089171== Content-Type: multipart/alternative; boundary="000000000000cadbc7059234f537" --000000000000cadbc7059234f537 Content-Type: text/plain; charset="UTF-8" On Mon, Sep 9, 2019 at 5:10 PM Adam Williamson <[email protected]> wrote: > On Mon, 2019-09-09 at 15:19 +0200, Vendula Poncova wrote: > > 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. > > This could work, however it's what I'd call "backwards UI" (I'm sure > there's a real term for it, but I'm not an expert so I don't know what > it is) - it's a pattern I find annoying because it makes you make > choices *before you know what the constraints are*, then tells you you > broke the mystery rules you didn't know about. ;) It's like password > systems that just say 'enter a password', then you enter one, and > *then* it says 'oh BTW it's meant to have more than 8 characters', so > you enter one with more than 8 characters and it says 'oh yeah and one > of them has to be upper case', so you upper case one, then it says 'oh > yeah and one has to be a special character', then you shoot the PC and > go herd yaks...:P > Warnings inform you about potential risks of your choices, but you are allowed to ignore them unlike the error messages you are talking about. It is like, when you enter a password with non-ASCII characters, the password system can say 'be careful, you might not be able to switch a keyboard layout when typing it', but you can still go ahead and use your password anyway. I would expect that users in general know what they are doing (I thought that is the premise of the Custom Partitioning Spoke), so I understand the warning about unsupported file systems as a disclaimer. -- > 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 > --000000000000cadbc7059234f537 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"></div><br><div class=3D"gmail_quote"><div= dir=3D"ltr" class=3D"gmail_attr">On Mon, Sep 9, 2019 at 5:10 PM Adam Willi= amson <<a href=3D"mailto:[email protected]" target=3D"_blank">a= [email protected]</a>> wrote:<br></div><blockquote class=3D"gmai= l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20= 4,204);padding-left:1ex">On Mon, 2019-09-09 at 15:19 +0200, Vendula Poncova= wrote:<br> > On Fri, Sep 6, 2019 at 3:02 AM Adam Williamson <<a href=3D"mailto:a= [email protected]" target=3D"_blank">[email protected]</a>= ><br> > wrote:<br> > <br> > > On Tue, 2019-09-03 at 13:38 -0400, David Lehman wrote:<br> > > > On Fri, 2019-08-23 at 12:16 -0700, Adam Williamson wrote:<br= > > > > > Hey folks!<br> > > > <br> > > > Hi Adam! Thanks for bringing this up again.<br> > > > <br> > > > > So...what should we do? Here are the options as I see &= #39;em:<br> > > > > <br> > > > > 1. Keep supporting btrfs<br> > > > > 2. Just modify the criterion with a btrfs exception, ev= en if it's<br> > > > > weird<br> > > > > 3. Rewrite the criterion entirely<br> > > > > 4. Keep btrfs support in the installer (and blivet-gui)= but hide it<br> > > > > as<br> > > > > we used to - require a special boot argument for it to = be visible<br> > > > > 5. Drop btrfs support from the installer<br> > > > <br> > > > I like option 3 most. The current criteria have always seeme= d, to me,<br> > > > too vague. I'd be happy to help hash out the details if/= when it<br> > > > happens.<br> > > <br> > > Thanks for the offer.<br> > > <br> > > So aside from the 'fun' of drafting very specific rules, = my concern<br> > > with #3 is we would then potentially be shipping an installer tha= t<br> > > presents things as roughly equal choices which are not in fact eq= ually<br> > > supported. You can pick 'btrfs' or 'ext4' from th= e 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'd prefer we indi= cate<br> > > somehow, somewhere, that all the choices are not equally guarante= ed to<br> > > be reliable. WDYT?<br> > > <br> > <br> > Hi Adam,<br> > <br> > I think that the best option is to add a new storage validation check = that<br> > will report a warning if a user wants to use a file system that is not= <br> > recommended by the installed product. The list of recommended file sys= tems<br> > would be provided by the Anaconda configuration files, so products and= <br> > variants could override it.<br> > <br> > We already show warnings with recommendations, for example for too sma= ll<br> > root partition or missing swap. The storage validation checks are run = for<br> > every type of partitioning, results are logged and warnings have to be= <br> > waved by the user in the interactive mode.<br> <br> This could work, however it's what I'd call "backwards UI"= ; (I'm sure<br> there's a real term for it, but I'm not an expert so I don't kn= ow what<br> it is) - it's a pattern I find annoying because it makes you make<br> choices *before you know what the constraints are*, then tells you you<br> broke the mystery rules you didn't know about. ;) It's like passwor= d<br> systems that just say 'enter a password', then you enter one, and<b= r> *then* it says 'oh BTW it's meant to have more than 8 characters= 9;, so<br> you enter one with more than 8 characters and it says 'oh yeah and one<= br> of them has to be upper case', so you upper case one, then it says '= ;oh<br> yeah and one has to be a special character', then you shoot the PC and<= br> go herd yaks...:P<br></blockquote><div><br></div><div>Warnings inform you a= bout potential risks of your choices, but you are allowed to ignore them un= like the error messages you are talking about. It is like, when you enter a= password with non-ASCII characters, the password system can say 'be ca= reful, you might not be able to switch a keyboard layout when typing it'= ;, but you can still go ahead and use your password anyway.</div><div><br><= /div><div>I would expect that users in general know what they are doing (I = thought that is the premise of the Custom Partitioning Spoke), so I underst= and the warning about unsupported file systems as a disclaimer.<br></div><d= iv> <br></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> --000000000000cadbc7059234f537-- --===============7745153007939089171== 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 --===============7745153007939089171==--