[Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs

[John.Florian at dart.biz]

> From: lists at colorremedies.com
> To: Bruno Wolff III <bruno at 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 at lists.fedoraproject.org
> 
> 
> On Feb 22, 2014, at 9:39 AM, Bruno Wolff III <bruno at wolff.to> wrote:
> 
> > On Fri, Feb 21, 2014 at 19:08:15 -0700,
> >  Chris Murphy <lists at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140224/a8aeaae3/attachment.html>