On Feb 21, 2014, at 2:38 PM, John.Florian@dart.biz wrote:
That makes a lot of sense, but I'd like to add that when doing custom partitioning, you can easily spend the bulk of your actual interaction time getting the partitioning customized exactly the way you want and when anaconda crashes,
What you're essentially suggesting is the necessary trade off between stability and features isn't being balanced, in your experience. I'd agree with that assessment. I've done hundreds of Windows installs and thousands of OS X installs and those installers never crash. Ever. Seriously never. You can throw the most bizarre crap at them, even a disk with 42 partitions of just linux and BSD and they don't crash. And what interaction time? It's point and install. There's nothing to interact with because there are no options.
However, when I have my admin hat on, I want flexibility.
I don't find that a compelling argument for many reasons, not least of which is the tens of thousands of OS X and Windows admins who get few install time layout choices, and they seem quite content. And they don't even have a kickstart equivalent, so I think it's fair to say flexibility is served by kickstart.
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. It only makes more work if I have to do an in place resize later on. Having LVM on those host makes that resizing oh so much simpler though, especially if additional drives are required.
I feel much the same about the /home partitioning and wish there was an checkbox in anaconda for that. Having a separate /home partition is good practice, but I never use the feature because mine is on NFS, so it makes for lots of click work to get the auto layout, then remove the home. (I did learn accidentally with btrfs I can just ignore it and I've not lost any space on /.)
So yes, simplicity is good, unless it makes everything else harder later.
Elsewhere the idea is that the OS installer actually just installs the OS successfully. After that comes such customizations that we are putting into the installer that really don't need to be in the installer. Post-install if I decide I want /home on NFS, if I want encrypted /home, if I want to buy another drive and put /home on raid1, what do I use? Not Anaconda, it's an install time specific tool.
The idea of what Anaconda can do to create powerful storage stacks with open source software has significant merit. But it's in the wrong place. It's an anchor on the installer, and can only be leveraged during an install of RHEL, CentOS or Fedora.
Chris Murphy
On Fri, Feb 21, 2014 at 19:08:15 -0700, Chris Murphy lists@colorremedies.com wrote:
The idea of what Anaconda can do to create powerful storage stacks with open source software has significant merit. But it's in the wrong place. It's an anchor on the installer, and can only be leveraged during an install of RHEL, CentOS or Fedora.
What would you have people do instead? For example run a live image to do the partitioning, raid, lvm, dmcrypt, and file system setup before doing the install? Even then, you need some way to tell the installer which directories go on which file systems for the install.
On Feb 22, 2014, at 9:39 AM, Bruno Wolff III bruno@wolff.to wrote:
On Fri, Feb 21, 2014 at 19:08:15 -0700, Chris Murphy lists@colorremedies.com wrote:
The idea of what Anaconda can do to create powerful storage stacks with open source software has significant merit. But it's in the wrong place. It's an anchor on the installer, and can only be leveraged during an install of RHEL, CentOS or Fedora.
What would you have people do instead? For example run a live image to do the partitioning, raid, lvm, dmcrypt, and file system setup before doing the install? Even then, you need some way to tell the installer which directories go on which file systems for the install.
I'm mainly suggesting a decoupling of all of this effort from an installation only context, so that it can be used to create and modify storage stacks without installing an OS. I don't particularly care how it manifests - separate app, or a spoke within the current app. Communicating the layout can be done with a fstab-like metadata file. If there's no inclination to do this for a much broader use case, then why wedge so much capability and effort into a narrow installer-only use case? Bootable raid6 and raid4??
Chris Murphy
On Sat, Feb 22, 2014 at 03:37:40PM -0700, Chris Murphy wrote:
On Feb 22, 2014, at 9:39 AM, Bruno Wolff III bruno@wolff.to wrote:
On Fri, Feb 21, 2014 at 19:08:15 -0700, Chris Murphy lists@colorremedies.com wrote:
The idea of what Anaconda can do to create powerful storage stacks with open source software has significant merit. But it's in the wrong place. It's an anchor on the installer, and can only be leveraged during an install of RHEL, CentOS or Fedora.
What would you have people do instead? For example run a live image to do the partitioning, raid, lvm, dmcrypt, and file system setup before doing the install? Even then, you need some way to tell the installer which directories go on which file systems for the install.
I'm mainly suggesting a decoupling of all of this effort from an installation only context, so that it can be used to create and modify storage stacks without installing an OS. I don't particularly care how it manifests - separate app, or a spoke within the current app. Communicating the layout can be done with a fstab-like metadata file. If there's no inclination to do this for a much broader use case, then why wedge so much capability and effort into a narrow installer-only use case? Bootable raid6 and raid4??
Decoupling can't happen given the hard requirement we have on supporting a wide range of storage configurations. Linux in general has far too many options in this area and everyone's corner case or configuration is most important.
So, just to chime in on one of these threads, I can speak to what we are working on in the installer camp right now:
1) Storage configuration and management outside of anaconda. The storage library was broken out as blivet and is growing to support use cases outside of the installer environment. This will open the door to doing things like using the storage UI in anaconda as a standalone management app (as an idea, for example).
2) Supporting alternative partitioning UI projects (both inside and outside of the installer). A number of very quiet people have asked about the feasability of creating another storage configuration UI in the installer. We absolutely do not have the workforce to support multiple storage configuration frontends, but if you want to explore that on your own, feel free. We encourage people to build on top of our blivet library as we have done, but the UI can be whatever you make it. In fact, the more people that try this will probably learn that "storage configuration" is a highly complicated and political topic. :)
3) Spoke development through our addon API. One thing I have noticed through the posts from Fedora working groups is the request for installation specifics. That's understandable given that the whole idea of the working groups finally admitted that we have multiple target use cases. Anaconda is positioned now to facilitate this through the addon API. Anaconda can grow spokes via plugins. We have a developer guide and the past two DevConf events in Brno have had presentations on how to write an addon for anaconda. With an addon you can:
a) Add a new spoke to the installer. b) Add a new text mode "spoke". c) Add a kickstart command. d) Add an initial-setup ("firstboot") spoke. And I will point out here that initial-setup in this context means the thing we wrote to replace our aging firstboot program. initial-setup is essentially the second hub in anaconda that runs when you first boot up the computer. It is not to be confused with gnome-initial-setup.
And that's sort of the high level stuff. If you have any questions you want to ask in this area, I am happy to talk one on one or in a time-bounded meeting. I, unfortunately, do not have the time, patience, or intestinal fortitude to participate in the working group email threads. I can only skim them occassionally. I saw this stuff and just wanted to chime in.
Thanks,
----- Original Message -----
On Sat, Feb 22, 2014 at 03:37:40PM -0700, Chris Murphy wrote:
On Feb 22, 2014, at 9:39 AM, Bruno Wolff III bruno@wolff.to wrote:
On Fri, Feb 21, 2014 at 19:08:15 -0700, Chris Murphy lists@colorremedies.com wrote:
The idea of what Anaconda can do to create powerful storage stacks with open source software has significant merit. But it's in the wrong place. It's an anchor on the installer, and can only be leveraged during an install of RHEL, CentOS or Fedora.
What would you have people do instead? For example run a live image to do the partitioning, raid, lvm, dmcrypt, and file system setup before doing the install? Even then, you need some way to tell the installer which directories go on which file systems for the install.
I'm mainly suggesting a decoupling of all of this effort from an installation only context, so that it can be used to create and modify storage stacks without installing an OS. I don't particularly care how it manifests - separate app, or a spoke within the current app. Communicating the layout can be done with a fstab-like metadata file. If there's no inclination to do this for a much broader use case, then why wedge so much capability and effort into a narrow installer-only use case? Bootable raid6 and raid4??
Decoupling can't happen given the hard requirement we have on supporting a wide range of storage configurations. Linux in general has far too many options in this area and everyone's corner case or configuration is most important.
Well, as Fedora.next aims pretty much on productization and we'd like to set higher bar for these products, I think we can limit these everyone's corner case configuration and focus on what's really needed for our main products. And I understand, this is really more politics than technical issue and we're right in this politics time of Fedora.next - a good time to rethink what we do now.
Of course the last but not least question is manpower of your team. There's possibility that if we would be able to simplify blocking paths in installer, we could get to the point there would be more time and will to touch proposed ideas...
Jaroslav
anaconda-devel@lists.stg.fedoraproject.org