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@xxxxxxxx> wrote:
>
> > On Fri, Feb 21, 2014 at 19:08:15 -0700,
> > Chris Murphy <lists@xxxxxxxxxxxxxxxxx> 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,
--
David Cantrell <dcantrell@xxxxxxxxxx>
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
