2014/1/9 Jeremy Hanmer <jer...@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 <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