Open Stack

Having run openstack clusters for ~2 years, I can't say that I've ever
desired such functionality.

How do you see these interactions defined?  For instance, if I deploy
a custom driver for Neutron, does that mean I also have to patch
everything that will be talking to it (Nova, for instance) so they can
agree on compatibility?

Also, I know that I run what is probably a more complicated cluster
than most production clusters, but I can't think of very many
configuration options that are globally in sync across the cluster.
Hypervisors, network drivers, mysql servers, API endpoints...they all
might vary between hosts/racks/etc.

On Thu, Jan 9, 2014 at 11:08 AM, Nachi Ueno <nachi at ntti3.com> 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?
>
> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>