On Fri, 2014-02-21 at 16:38 -0500, John.Florian@dart.biz wrote:
With the best of intentions, we'd gone from a reluctant exception to the 'no choice' design to a dropdown which included two very different complex choices: LVM and btrfs. So now the installer path which was originally supposed to be minimal-choice, very robust and testable and fixable, had become rather a lot more complex.
Everything should be made as simple as possible, but not simpler.
I don't think that precept applies very well to this area.
The problem is that there are - and this is probably *literal*, not a rhetorical flourish - millions of Special Little Use Cases like yours (the one below, snipped for brevity) out there. *You* want it to be easy to skip /home. *She* wants it to be easy to resize a Slackware install. *That guy* wants to use btrfs. *My cat* likes RAID. It is becoming very, very clear that we just cannot undertake to support them all and guarantee that they are all going to work in a release. It's just _too much work_. Everyone agrees that it would be nice if we could, but then everyone agrees that it'd be nice if I had a solid gold toilet. Some nice things just don't happen. We do not have the resources to be in the business of writing the world's biggest disk configuration tool and guaranteeing that it'll never go wrong, which isn't *quite* what we're currently trying to do, but it's not far from it.
It's worth trying some other installers out, just to reset your expectations. Have you seen the level of flexibility you get from Ubuntu's interactive installer? Windows'? OS X's?
I appreciate your QA angle here. Every condition in a code path leads to exponential growth in testing.
And development. This isn't just a QA problem. We do not have the development resources to commit to all this stuff working reliably every six months.
However, when I have my admin hat on, I want flexibility. I love LVM for that reason. However, if I'm setting up simple VMs whose backend storage resides in a LV, I have no need or desire for LVM within the VM.
Does it hurt you to get it, though? I do my VM installs with LVs. I don't really need them. But nothing explodes, and two hours later I forget all about it. In the end it's just bits. As long as the bits are where they need to be when things need to read them, who *gives* a monkey's tail?
I did recognize that it would be tough sledding to get back to zero choice, and if you ask me to crystal ball it, we might have to wind up back at 'plain partitions or LVM'. But that's still a substantial improvement on where we are right now.
On Fri, Feb 21, 2014 at 02:04:54PM -0800, Adam Williamson wrote:
On Fri, 2014-02-21 at 16:38 -0500, John.Florian@dart.biz wrote:
With the best of intentions, we'd gone from a reluctant exception to the 'no choice' design to a dropdown which included two very different complex choices: LVM and btrfs. So now the installer path which was originally supposed to be minimal-choice, very robust and testable and fixable, had become rather a lot more complex.
Everything should be made as simple as possible, but not simpler.
I don't think that precept applies very well to this area.
The problem is that there are - and this is probably *literal*, not a rhetorical flourish - millions of Special Little Use Cases like yours (the one below, snipped for brevity) out there. *You* want it to be easy to skip /home. *She* wants it to be easy to resize a Slackware install. *That guy* wants to use btrfs. *My cat* likes RAID. It is becoming very, very clear that we just cannot undertake to support them all and guarantee that they are all going to work in a release. It's just _too much work_. Everyone agrees that it would be nice if we could, but then everyone agrees that it'd be nice if I had a solid gold toilet. Some nice things just don't happen. We do not have the resources to be in the business of writing the world's biggest disk configuration tool and guaranteeing that it'll never go wrong, which isn't *quite* what we're currently trying to do, but it's not far from it.
Don't try to be smart to everyone, it does not work. IMHO all you need is to support one or a very few scenarios (complete scenarios without customization) and a way how to switch from installer to manual partitioning by parted/fdisk/mdadm/mkfs/etc.
The anaconda partitioning UI will never be smart enough for advanced users and it also does not make sense to duplicate effort, we *already have* tools to create all the unusual crazy disk layouts.
Karel
On Wed, 2014-02-26 at 11:17 +0100, Karel Zak wrote:
Don't try to be smart to everyone, it does not work. IMHO all you need is to support one or a very few scenarios (complete scenarios without customization) and a way how to switch from installer to manual partitioning by parted/fdisk/mdadm/mkfs/etc.
The anaconda partitioning UI will never be smart enough for advanced users and it also does not make sense to duplicate effort, we *already have* tools to create all the unusual crazy disk layouts.
We don't, really. Well, we do, but it really is "tools" plural, and some of them don't have GUIs at all. blivet and its anaconda GUI really is one of the most advanced partitioning tools in existence. There's no one-stop graphical tool that does everything blivet/anaconda does, AFAIK. gparted can't do anywhere near the LVM, RAID and btrfs stuff that blivet does: it really only does *partitions*.
We've kind of boxed ourselves into a corner of unreasonably high expectations here now, though - we either commit to continuing to support all the functionality custom part currently supports, or we say "reduce it and screw the complainers", but there *will* be complainers. There already are quite vociferous complainers for the very small amount of simplification that was done between oldUI custom part and newUI custom part.
Possibly the most viable long-term option, and I think one the devs are gradually working towards, is to make the blivet GUI an independent component. That would mean it wouldn't kill your whole anaconda run if it crashed (you could just start over and try again), and you could use it from outside of anaconda (say, to pre-partition). And it'd maybe encourage other projects to adopt and contribute to it, which would definitely help take the load off - I've said it before but I'll say it again, it is kinda absurd that we have, what, about the equivalent of 1.5 full-time developers trying to maintain this extremely capable and complex partitioning backend *and* frontend.
It would certainly make life much easier on us if we said 'screw it, disks are hard, let's go shopping' and just outsourced all the partitioning to gparted (like ubiquity does), but it'd definitely be a substantial drop in capability compared to what we have now. (And I doubt it'd be acceptable for RHEL, so in the end the same people would have to work on it anyway even if Fedora wasn't using it.)
On Wed, 2014-02-26 at 11:46 -0800, Adam Williamson wrote:
On Wed, 2014-02-26 at 11:17 +0100, Karel Zak wrote:
Don't try to be smart to everyone, it does not work. IMHO all you need is to support one or a very few scenarios (complete scenarios without customization) and a way how to switch from installer to manual partitioning by parted/fdisk/mdadm/mkfs/etc.
The anaconda partitioning UI will never be smart enough for advanced users and it also does not make sense to duplicate effort, we *already have* tools to create all the unusual crazy disk layouts.
We don't, really. Well, we do, but it really is "tools" plural, and some of them don't have GUIs at all. blivet and its anaconda GUI really is one of the most advanced partitioning tools in existence. There's no one-stop graphical tool that does everything blivet/anaconda does, AFAIK. gparted can't do anywhere near the LVM, RAID and btrfs stuff that blivet does: it really only does *partitions*.
Just to let you know -- a guy from Prague Technical University is working on a bachelor thesis [1] focused on starting the development of a GUI partitioning/LVM/RAID/BTRFS tool based on blivet that should be embedable into other applications, Anaconda included.
We've kind of boxed ourselves into a corner of unreasonably high expectations here now, though - we either commit to continuing to support all the functionality custom part currently supports, or we say "reduce it and screw the complainers", but there *will* be complainers. There already are quite vociferous complainers for the very small amount of simplification that was done between oldUI custom part and newUI custom part.
Possibly the most viable long-term option, and I think one the devs are gradually working towards, is to make the blivet GUI an independent component. That would mean it wouldn't kill your whole anaconda run if it crashed (you could just start over and try again), and you could use it from outside of anaconda (say, to pre-partition). And it'd maybe encourage other projects to adopt and contribute to it, which would definitely help take the load off - I've said it before but I'll say it again, it is kinda absurd that we have, what, about the equivalent of 1.5 full-time developers trying to maintain this extremely capable and complex partitioning backend *and* frontend.
Another "let you know" -- I'm now starting to work on blivet for most of my work hours, so it will hopefully soon be equivalent of 2.5 full-time developers.
Also, we have already discussed splitting out the Custom partitioning GUI into a separate tool with dlehman. I can soon (in March) jump on it and I believe it should be feasible.
On Thu, 2014-02-27 at 09:17 +0100, Vratislav Podzimek wrote:
On Wed, 2014-02-26 at 11:46 -0800, Adam Williamson wrote:
On Wed, 2014-02-26 at 11:17 +0100, Karel Zak wrote:
Don't try to be smart to everyone, it does not work. IMHO all you need is to support one or a very few scenarios (complete scenarios without customization) and a way how to switch from installer to manual partitioning by parted/fdisk/mdadm/mkfs/etc.
The anaconda partitioning UI will never be smart enough for advanced users and it also does not make sense to duplicate effort, we *already have* tools to create all the unusual crazy disk layouts.
We don't, really. Well, we do, but it really is "tools" plural, and some of them don't have GUIs at all. blivet and its anaconda GUI really is one of the most advanced partitioning tools in existence. There's no one-stop graphical tool that does everything blivet/anaconda does, AFAIK. gparted can't do anywhere near the LVM, RAID and btrfs stuff that blivet does: it really only does *partitions*.
Just to let you know -- a guy from Prague Technical University is working on a bachelor thesis [1] focused on starting the development of a GUI partitioning/LVM/RAID/BTRFS tool based on blivet that should be embedable into other applications, Anaconda included.
The omitted link: [1] https://thesis-managementsystem.rhcloud.com/topic/show/180/a-tool-for-storag...
anaconda-devel@lists.stg.fedoraproject.org