Open Stack

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 <clint at 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 <nachi at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev