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

Jaroslav Reznik jreznik at redhat.com
Mon Feb 24 14:51:26 UTC 2014


----- 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 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??
> > 
> 
> 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


More information about the server mailing list