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
From: lists@colorremedies.com To: Bruno Wolff III bruno@wolff.to Date: 02/22/2014 17:38 Subject: Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs Sent by: devel-bounces@lists.fedoraproject.org
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??
I actually like that idea of decoupling them. It would be good to see more of the *nix tradition here, do ONE thing and do it very well. Of course we'd need the two things (storage stack manager and installer) and the fun would be in making them appear seamless.
-- John Florian
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
I know a little about guided and custom partitioning. Custom is a bit too complex for the new users. The guided/automated partioning is the best.
Harken back to F16 my friends.
We lost a lot of important progress, I think. I was in love with F16 and I was running it "flawlessly" until F17 came out with major major bugs. Luckily you guys rock and knocked out all the fucking bugs, next problem is simple: Keeping it user-friendly. The average linux dabbler is not going to persist if there are more bugs in F20. For example, I am a bit of an intermediate user and even I was unable to get F20 up and running smoothly--- I had the opening screen dump (our favorite logo!) followed by being thrown into a kernel thrash and having to switch back and forth between dracut and bash like a fkn novice.
So anyways, let's keep it simpler for our noobs. And I think a meet is a great idea-- let's plan for a month or so out? I know I'm not on the developer team, but I am an active user!
Thanks -Matt (don't be mad at the Knoppix logos) :)
------ Powered by:
On Monday, February 24, 2014 10:51 PM, Jaroslav Reznik jreznik@redhat.com wrote:
----- 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
server@lists.fedoraproject.org
-
Bruno Wolff III -
Chris Murphy -
David Cantrell -
Jaroslav Reznik -
John.Florian＠dart.biz -
matt palsson