Hi folks Thank you for your input.
The key difference from external configuration system (Chef, puppet etc) is integration with openstack services. There are cases a process should know the config value in the other hosts. If we could have centralized config storage api, we can solve this issue. One example of such case is neuron + nova vif parameter configuration regarding to security group. The workflow is something like this. nova asks vif configuration information for neutron server. Neutron server ask configuration in neutron l2-agent on the same host of nova-compute. host1 neutron server nova-api host2 neturon l2-agent nova-compute In this case, a process should know the config value in the other hosts. Replying some questions > Adding a config server would dramatically change the way that configuration management tools would interface with OpenStack services. [Jay] Since this bp is just adding "new mode", we can still use existing config files. > why not help to make Chef or Puppet better and cover the more OpenStack > use-cases rather than add yet another competing system [Doug, Morgan] I believe this system is not competing system. The key point is we should have some standard api to access such services. As Oleg suggested, we can use sql-server, kv-store, or chef or puppet as a backend system. Best Nachi 2014/1/9 Morgan Fainberg <m...@metacloud.com>: > I agree with Doug’s question, but also would extend the train of thought to > ask why not help to make Chef or Puppet better and cover the more OpenStack > use-cases rather than add yet another competing system? > > Cheers, > Morgan > > On January 9, 2014 at 10:24:06, Doug Hellmann (doug.hellm...@dreamhost.com) > wrote: > > What capabilities would this new service give us that existing, proven, > configuration management tools like chef and puppet don't have? > > > On Thu, Jan 9, 2014 at 12:52 PM, Nachi Ueno <na...@ntti3.com> wrote: >> >> Hi Flavio >> >> Thank you for your input. >> I agree with you. oslo.config isn't right place to have server side code. >> >> How about oslo.configserver ? >> For authentication, we can reuse keystone auth and oslo.rpc. >> >> Best >> Nachi >> >> >> 2014/1/9 Flavio Percoco <fla...@redhat.com>: >> > 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. >> > >> > That's all I've got for now, >> > FF >> > >> > -- >> > @flaper87 >> > Flavio Percoco >> > >> > _______________________________________________ >> > 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