Open Stack

Hi Doug

Thank you for your input.

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

Essentially, A configuration is a API.
I don't think every configuration is a kind of  low level
configuration (timeout etc).
Some configuration should tell  "how do I connect a VIF for this instance",
and we should select high level design configuration parameters.

> 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
>> >> >
>> >
>> >
>
>