Open Stack

+1 to Jay.  Existing tools are both better suited to the job and work
quite well in their current state.  To address Nachi's first example,
there's nothing preventing a Nova node in Chef from reading Neutron's
configuration (either by using a (partial) search or storing the
necessary information in the environment rather than in roles).  I
assume Puppet offers the same.  Please don't re-invent this hugely
complicated wheel.

On Thu, Jan 9, 2014 at 10:28 AM, Jay Pipes <jaypipes at gmail.com> wrote:
> On Thu, 2014-01-09 at 10:23 +0100, Flavio Percoco wrote:
>> On 08/01/14 17:13 -0800, Nachi Ueno wrote:
>> >Hi folks
>> >
>> >OpenStack process tend to have many config options, and many hosts.
>> >It is a pain to manage this tons of config options.
>> >To centralize this management helps operation.
>> >
>> >We can use chef or puppet kind of tools, however
>> >sometimes each process depends on the other processes configuration.
>> >For example, nova depends on neutron configuration etc
>> >
>> >My idea is to have config server in oslo.config, and let cfg.CONF get
>> >config from the server.
>> >This way has several benefits.
>> >
>> >- We can get centralized management without modification on each
>> >projects ( nova, neutron, etc)
>> >- We can provide horizon for configuration
>> >
>> >This is bp for this proposal.
>> >https://blueprints.launchpad.net/oslo/+spec/oslo-config-centralized
>> >
>> >I'm very appreciate any comments on this.
>>
>> I've thought about this as well. I like the overall idea of having a
>> config server. However, I don't like the idea of having it within
>> oslo.config. I'd prefer oslo.config to remain a library.
>>
>> Also, I think it would be more complex than just having a server that
>> provides the configs. It'll need authentication like all other
>> services in OpenStack and perhaps even support of encryption.
>>
>> I like the idea of a config registry but as mentioned above, IMHO it's
>> to live under its own project.
>
> Hi Nati and Flavio!
>
> So, I'm -1 on this idea, just because I think it belongs in the realm of
> configuration management tooling (Chef/Puppet/Salt/Ansible/etc). Those
> tools are built to manage multiple configuration files and changes in
> them. Adding a config server would dramatically change the way that
> configuration management tools would interface with OpenStack services.
> Instead of managing the config file templates as all of the tools
> currently do, the tools would need to essentially need to forego the
> tried-and-true INI files and instead write a bunch of code in order to
> deal with REST API set/get operations for changing configuration data.
>
> In summary, while I agree that OpenStack services have an absolute TON
> of configurability -- for good and bad -- there are ways to improve the
> usability of configuration without changing the paradigm that most
> configuration management tools expect. One such example is having
> include.d/ support -- similar to the existing oslo.cfg module's support
> for a --config-dir, but more flexible and more like what other open
> source programs (like Apache) have done for years.
>
> All the best,
> -jay
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>