Open Stack

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
Chef-world).

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
experience.

All the best,
-jay