Open Stack

On Thu, Jan 9, 2014 at 2:34 PM, Nachi Ueno <nachi at ntti3.com> wrote:

> Hi Doug
>
> 2014/1/9 Doug Hellmann <doug.hellmann at dreamhost.com>:
> >
> >
> >
> > 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.
>
> 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.

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 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/bcb62248/attachment.html>