+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 <jaypi...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev