Open Stack

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.

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.

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 at 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.hellmann at 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 <nachi at 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 <flavio at 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 at lists.openstack.org
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140109/707f060c/attachment.html>