Open Stack

On Fri, Jan 10, 2014 at 4:01 AM, Mark McLoughlin <markmc at redhat.com> wrote:

> On Thu, 2014-01-09 at 16:34 -0800, Joe Gordon wrote:
> > On Thu, Jan 9, 2014 at 3:01 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> >
> > > On Thu, 2014-01-09 at 23:56 +0100, Julien Danjou wrote:
> > > > On Thu, Jan 09 2014, Jay Pipes wrote:
> > > >
> > > > > Hope you don't mind, I'll jump in here :)
> > > > >
> > > > > On Thu, 2014-01-09 at 11:08 -0800, Nachi Ueno wrote:
> > > > >> Hi Jeremy
> > > > >>
> > > > >> Don't you think it is burden for operators if we should choose
> correct
> > > > >> combination of config for multiple nodes even if we have chef and
> > > > >> puppet?
> > > > >
> > > > > It's more of a burden for operators to have to configure OpenStack
> in
> > > > > multiple ways.
> > > >
> > > > I also think projects should try to minimize configuration options at
> > > > their minimum so operators are completely lost. Opening the sample
> > > > nova.conf and seeing 696 options is not what I would call user
> friendly.
> > > >
> > >
> >
> >
> > There was talk a while back about marking different config options as
> basic
> > and advanced (or something along those lines) to help make it easier for
> > operators.
>
> You might be thinking of this session summit I led:
>
>   https://etherpad.openstack.org/p/grizzly-nova-config-options
>
> My thinking was we first move config options into groups to make it
> easier for operators to make sense of the available options and then we
> would classify them (as e.g. "tuning", "experimental", "debug") and
> exclude some classifications from the sample config file.
>
> Sadly, I never even made good progress on "Tedious Task 2 :: Group".
>


That is exactly what I was thinking of.


>
> Mark.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140110/f6bb19fb/attachment.html>