On Thu, 2014-01-09 at 16:34 -0800, Joe Gordon wrote: > On Thu, Jan 9, 2014 at 3:01 PM, Jay Pipes <[email protected]> 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". Mark. _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
