Open Stack

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?

If we have some constraint or dependency in configurations, such logic
should be in openstack source code.
We can solve this issue if we have a standard way to know the config
value of other process in the other host.

Something like this.
self.conf.host('host1').firewall_driver

Then we can have a chef/or file baed config backend code for this for example.

Best
Nachi


2014/1/9 Jeremy Hanmer <jeremy at dreamhost.com>:
> +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
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev