Open Stack

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.