Hi Oleg 2014/1/9 Oleg Gelbukh <ogelb...@mirantis.com>: > On Fri, Jan 10, 2014 at 12:18 AM, Nachi Ueno <na...@ntti3.com> wrote: >> >> 2014/1/9 Jeremy Hanmer <jer...@dreamhost.com>: >> >> > 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. > > > 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.
I agree. This is a my current choice. > -- > Best regards, > Oleg Gelbukh > >> >> >> > 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 <na...@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 <jer...@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 <jaypi...@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@lists.openstack.org >> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >>>> >> >>> >> >>> _______________________________________________ >> >>> OpenStack-dev mailing list >> >>> OpenStack-dev@lists.openstack.org >> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> _______________________________________________ >> >> OpenStack-dev mailing list >> >> OpenStack-dev@lists.openstack.org >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> > >> > _______________________________________________ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev