Hi Doug Thank you for your input.
2014/1/9 Doug Hellmann <doug.hellm...@dreamhost.com>: > > > > On Thu, Jan 9, 2014 at 2:34 PM, Nachi Ueno <na...@ntti3.com> wrote: >> >> Hi Doug >> >> 2014/1/9 Doug Hellmann <doug.hellm...@dreamhost.com>: >> > >> > >> > >> > On Thu, Jan 9, 2014 at 1:53 PM, Nachi Ueno <na...@ntti3.com> wrote: >> >> >> >> 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. >> > >> > >> > That extra round trip does sound like a potential performance >> > bottleneck, >> > but sharing the configuration data directly is not the right solution. >> > If >> > the configuration setting names are shared, they become part of the >> > integration API between the two services. Nova should ask neutron how to >> > connect the VIF, and it shouldn't care how neutron decides to answer >> > that >> > question. The configuration setting is an implementation detail of >> > neutron >> > that shouldn't be exposed directly to nova. >> >> I agree for nova - neutron if. >> However, neutron server and neutron l2 agent configuration depends on >> each other. >> >> >> > Running a configuration service also introduces what could be a single >> > point >> > of failure for all of the other distributed services in OpenStack. An >> > out-of-band tool like chef or puppet doesn't result in the same sort of >> > situation, because the tool does not have to be online in order for the >> > cloud to be online. >> >> We can choose same implementation. ( Copy information in local cache etc) >> >> Thank you for your input, I could organize my thought. >> My proposal can be split for the two bps. >> >> [BP1] conf api for the other process >> Provide standard way to know the config value in the other process in >> same host or the other host. > > > Please don't do this. It's just a bad idea to expose the configuration > settings between apps this way, because it couples the applications tightly > at a low level, instead of letting the applications have APIs for sharing > logical information at a high level. It's the difference between asking > "what is the value of a specific configuration setting on a particular > hypervisor" and asking "how do I connect a VIF for this instance". The > latter lets you provide different answers based on context. The former > doesn't. Essentially, A configuration is a API. I don't think every configuration is a kind of low level configuration (timeout etc). Some configuration should tell "how do I connect a VIF for this instance", and we should select high level design configuration parameters. > Doug > > >> >> >> - API Example: >> conf.host('host1').firewall_driver >> >> - Conf file baed implementaion: >> config for each host will be placed in here. >> /etc/project/conf.d/{hostname}/agent.conf >> >> [BP2] Multiple backend for storing config files >> >> Currently, we have only file based configration. >> In this bp, we are extending support for config storage. >> - KVS >> - SQL >> - Chef - Ohai >> >> >> Best >> Nachi >> >> > Doug >> > >> > >> >> >> >> >> >> 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