Hi Flavio, Clint I agree with you guys. sorry, may be, I wasn't clear. My opinion is to remove every configuration in the node, and every configuration should be done by API from central resource manager. (nova-api or neturon server etc).
This is how to add new hosts, in cloudstack, vcenter, and openstack. Cloudstack: "Go to web UI, add Host/ID/PW". http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.0.2/html/Installation_Guide/host-add.html vCenter: "Go to vsphere client, Host/ID/PW". https://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.solutions.doc%2FGUID-A367585C-EB0E-4CEB-B147-817C1E5E8D1D.html Openstack, - Manual - setup mysql connection config, rabbitmq/qpid connection config, keystone config,, neturon config, xxxx http://docs.openstack.org/havana/install-guide/install/apt/content/nova-compute.html We have some deployment system including chef / puppet / packstack, TripleO - Chef/Puppet Setup chef node Add node/ apply role - Packstack - Generate answer file https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/2/html/Getting_Started_Guide/sect-Running_PackStack_Non-interactively.html - packstack --install-hosts=192.168.1.0,192.168.1.1,192.168.1.2 - TripleO - UnderCloud nova baremetal node add - OverCloud modify heat template For residence in this mailing list, Chef/Puppet or third party tool is easy to use. However, I believe they are magical tools to use for many operators. Furthermore, these development system tend to take time to support newest release. so most of users, OpenStack release didn't means it can be usable for them. IMO, current way to manage configuration is the cause of this issue. If we manage everything via API, we can manage cluster by horizon. Then user can do "go to horizon, just add host". It may take time to migrate config to API, so one easy step is to convert existing config for API resources. This is the purpose of this proposal. Best Nachi 2014/1/10 Clint Byrum <cl...@fewbar.com>: > Excerpts from Doug Hellmann's message of 2014-01-09 12:21:05 -0700: >> 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. >> > > That is where I think my resistance to such a change starts. If Nova and > Neutron need to share a value, they should just do that via their API's. > There is no need for a config server in the middle. If it is networking > related, it lives in Neutron's configs, and if it is compute related, > Nova's configs. > > Is there any example where values need to be in sync but are not > sharable via normal API chatter? > >> 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. >> > > Configuration shouldn't ever have a rapid pattern of change, so even if > this service existed I'd suggest that it would be used just like current > config management solutions: scrape values out, write to config files. > > _______________________________________________ > 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