> 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