<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 10, 2014 at 12:18 AM, Nachi Ueno <span dir="ltr"><<a href="mailto:nachi@ntti3.com" target="_blank">nachi@ntti3.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2014/1/9 Jeremy Hanmer <<a href="mailto:jeremy@dreamhost.com">jeremy@dreamhost.com</a>>:<br>
<div class="im">> How do you see these interactions defined? For instance, if I deploy<br></div><div class="im">
> a custom driver for Neutron, does that mean I also have to patch<br>
> everything that will be talking to it (Nova, for instance) so they can<br>
> agree on compatibility?<br>
<br>
</div>Nova / Neutron talks with neturon api. so it should be OK because we<br>
are talking care<br>
backward compatibility in the REST API.<br>
<br>
The point in my example is neutron server + neutron l2 agent sync.<br></blockquote><div><br></div><div>What about doing it the other way round, i.e. allow one server to query certain configuration parameter(s) from the other via RPC? I believe I've seen such proposal quite some time ago in Nova blueprints, but with no actual implementation.</div>
<div><br></div><div>--</div><div>Best regards,</div><div>Oleg Gelbukh</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> Also, I know that I run what is probably a more complicated cluster<br>
> than most production clusters, but I can't think of very many<br>
> configuration options that are globally in sync across the cluster.<br>
> Hypervisors, network drivers, mysql servers, API endpoints...they all<br>
> might vary between hosts/racks/etc.<br>
<br>
</div>To support such heterogeneous environment is a purpose of this bp.<br>
Configuration dependency is pain point for me, and it's get more worse<br>
if the env is heterogeneous.<br>
<br>
I have also some experience to run openstack clusters, but it is still<br>
pain for me..<br>
<br>
My experience is something like this<br>
# Wow, new release! ohh this chef repo didn't supported..<br>
# hmm i should modify chef recipe.. hmm debug.. debug..<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> On Thu, Jan 9, 2014 at 11:08 AM, Nachi Ueno <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>> wrote:<br>
>> Hi Jeremy<br>
>><br>
>> Don't you think it is burden for operators if we should choose correct<br>
>> combination of config for multiple nodes even if we have chef and<br>
>> puppet?<br>
>><br>
>> If we have some constraint or dependency in configurations, such logic<br>
>> should be in openstack source code.<br>
>> We can solve this issue if we have a standard way to know the config<br>
>> value of other process in the other host.<br>
>><br>
>> Something like this.<br>
>> self.conf.host('host1').firewall_driver<br>
>><br>
>> Then we can have a chef/or file baed config backend code for this for example.<br>
>><br>
>> Best<br>
>> Nachi<br>
>><br>
>><br>
>> 2014/1/9 Jeremy Hanmer <<a href="mailto:jeremy@dreamhost.com">jeremy@dreamhost.com</a>>:<br>
>>> +1 to Jay. Existing tools are both better suited to the job and work<br>
>>> quite well in their current state. To address Nachi's first example,<br>
>>> there's nothing preventing a Nova node in Chef from reading Neutron's<br>
>>> configuration (either by using a (partial) search or storing the<br>
>>> necessary information in the environment rather than in roles). I<br>
>>> assume Puppet offers the same. Please don't re-invent this hugely<br>
>>> complicated wheel.<br>
>>><br>
>>> On Thu, Jan 9, 2014 at 10:28 AM, Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br>
>>>> On Thu, 2014-01-09 at 10:23 +0100, Flavio Percoco wrote:<br>
>>>>> On 08/01/14 17:13 -0800, Nachi Ueno wrote:<br>
>>>>> >Hi folks<br>
>>>>> ><br>
>>>>> >OpenStack process tend to have many config options, and many hosts.<br>
>>>>> >It is a pain to manage this tons of config options.<br>
>>>>> >To centralize this management helps operation.<br>
>>>>> ><br>
>>>>> >We can use chef or puppet kind of tools, however<br>
>>>>> >sometimes each process depends on the other processes configuration.<br>
>>>>> >For example, nova depends on neutron configuration etc<br>
>>>>> ><br>
>>>>> >My idea is to have config server in oslo.config, and let cfg.CONF get<br>
>>>>> >config from the server.<br>
>>>>> >This way has several benefits.<br>
>>>>> ><br>
>>>>> >- We can get centralized management without modification on each<br>
>>>>> >projects ( nova, neutron, etc)<br>
>>>>> >- We can provide horizon for configuration<br>
>>>>> ><br>
>>>>> >This is bp for this proposal.<br>
>>>>> ><a href="https://blueprints.launchpad.net/oslo/+spec/oslo-config-centralized" target="_blank">https://blueprints.launchpad.net/oslo/+spec/oslo-config-centralized</a><br>
>>>>> ><br>
>>>>> >I'm very appreciate any comments on this.<br>
>>>>><br>
>>>>> I've thought about this as well. I like the overall idea of having a<br>
>>>>> config server. However, I don't like the idea of having it within<br>
>>>>> oslo.config. I'd prefer oslo.config to remain a library.<br>
>>>>><br>
>>>>> Also, I think it would be more complex than just having a server that<br>
>>>>> provides the configs. It'll need authentication like all other<br>
>>>>> services in OpenStack and perhaps even support of encryption.<br>
>>>>><br>
>>>>> I like the idea of a config registry but as mentioned above, IMHO it's<br>
>>>>> to live under its own project.<br>
>>>><br>
>>>> Hi Nati and Flavio!<br>
>>>><br>
>>>> So, I'm -1 on this idea, just because I think it belongs in the realm of<br>
>>>> configuration management tooling (Chef/Puppet/Salt/Ansible/etc). Those<br>
>>>> tools are built to manage multiple configuration files and changes in<br>
>>>> them. Adding a config server would dramatically change the way that<br>
>>>> configuration management tools would interface with OpenStack services.<br>
>>>> Instead of managing the config file templates as all of the tools<br>
>>>> currently do, the tools would need to essentially need to forego the<br>
>>>> tried-and-true INI files and instead write a bunch of code in order to<br>
>>>> deal with REST API set/get operations for changing configuration data.<br>
>>>><br>
>>>> In summary, while I agree that OpenStack services have an absolute TON<br>
>>>> of configurability -- for good and bad -- there are ways to improve the<br>
>>>> usability of configuration without changing the paradigm that most<br>
>>>> configuration management tools expect. One such example is having<br>
>>>> include.d/ support -- similar to the existing oslo.cfg module's support<br>
>>>> for a --config-dir, but more flexible and more like what other open<br>
>>>> source programs (like Apache) have done for years.<br>
>>>><br>
>>>> All the best,<br>
>>>> -jay<br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> OpenStack-dev mailing list<br>
>>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>><br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>