[openstack-dev] [oslo.config] Centralized config management

Jay Pipes jaypipes at gmail.com
Thu Jan 9 20:40:20 UTC 2014

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.

> If we have some constraint or dependency in configurations, such logic
> should be in openstack source code.

Could you explain this a bit more? I generally view packages and things
like requirements.txt and setup.py [extra] sections as the canonical way
of resolving dependencies. An example here would be great.

> 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

This is already in every configuration management system I can think of.

In Chef, a cookbook can call out to search (or partial search) for the
node in question and retrieve such information (called attributes in

In Puppet, one would use Hiera to look up another node's configuration.

In Ansible, one would use a "Dynamic Inventory".

In Salt, you'd use Salt Mine.

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

I actually think you're thinking about this in the reverse way to the
way operators think about things. Operators want all configuration data
managed by a singular system -- their configuration management system.
Adding a different configuration data manager into the mix is the
opposite of what most operators would like, at least, that's just in my

All the best,

More information about the OpenStack-dev mailing list