Open Stack

2014/1/9 Jeremy Hanmer <jeremy at dreamhost.com>:
> Having run openstack clusters for ~2 years, I can't say that I've ever
> desired such functionality.

My proposal is adding functionalities, not removing it.
so if you are satisfied with file based configuration with chef or puppet,
this change won't affect you

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

Nova / Neutron talks with neturon api. so it should be OK because we
are talking care
backward compatibility in the REST API.

The point in my example is neutron server + neutron l2 agent sync.

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

To support such heterogeneous environment is a purpose of this bp.
Configuration dependency is pain point for me, and it's get more worse
if the env is heterogeneous.

I have also some experience to run openstack clusters, but it is still
pain for me..

My experience is something like this
# Wow, new release! ohh this chef repo didn't supported..
# hmm i should modify chef recipe.. hmm debug.. debug..


> 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
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev