Open Stack

Hi Jay

2014/1/9 Jay Pipes <jaypipes at gmail.com>:
> Hope you don't mind, I'll jump in here :)
I'll never mind to discuss with you :)

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

This is independent discussion with pain of dependent configuration in
multiple node.

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

It's package dependencies. I'm talking about configuration
dependencies or constraint.
For example, if we wanna use VLAN with neutron,
we should do proper configuration in neutron server and nova-compute
and l2-agent.

We get input such as this is a burden for operation.

Then neutron team start working on port binding extension to reduce this burden.
This extension let nova ask neutron for vif configuration, then we can remove
any redundant network configuration in nova.conf.

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

Yes. I agree. But we can't assess it from inside of the openstack code.

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

My point is let openstack access the "single" configuration management system.
Also, I wanna reduce redundant configuration in between multiple
nodes, and hopefully,
 we could have some generic framework to do this.

Nachi

> All the best,
> -jay
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev