[openstack-dev] [oslo.config] Centralized config management
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
It's more of a burden for operators to have to configure OpenStack in
> 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.
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