Open Stack

Hi Oleg

2014/1/9 Oleg Gelbukh <ogelbukh at mirantis.com>:
> On Fri, Jan 10, 2014 at 12:18 AM, Nachi Ueno <nachi at ntti3.com> wrote:
>>
>> 2014/1/9 Jeremy Hanmer <jeremy at dreamhost.com>:
>>
>> > How do you see these interactions defined?  For instance, if I deploy
>> > a custom driver for Neutron, does that mean I also have to patch
>> > everything that will be talking to it (Nova, for instance) so they can
>> > agree on compatibility?
>>
>> Nova / Neutron talks with neturon api. so it should be OK because we
>> are talking care
>> backward compatibility in the REST API.
>>
>> The point in my example is neutron server + neutron l2 agent sync.
>
>
> What about doing it the other way round, i.e. allow one server to query
> certain configuration parameter(s) from the other via RPC? I believe I've
> seen such proposal quite some time ago in Nova blueprints, but with no
> actual implementation.

I agree. This is a my current choice.

> --
> Best regards,
> Oleg Gelbukh
>
>>
>>
>> > Also, I know that I run what is probably a more complicated cluster
>> > than most production clusters, but I can't think of very many
>> > configuration options that are globally in sync across the cluster.
>> > Hypervisors, network drivers, mysql servers, API endpoints...they all
>> > might vary between hosts/racks/etc.
>>
>> To support such heterogeneous environment is a purpose of this bp.
>> Configuration dependency is pain point for me, and it's get more worse
>> if the env is heterogeneous.
>>
>> I have also some experience to run openstack clusters, but it is still
>> pain for me..
>>
>> My experience is something like this
>> # Wow, new release! ohh this chef repo didn't supported..
>> # hmm i should modify chef recipe.. hmm debug.. debug..
>>
>>
>> > On Thu, Jan 9, 2014 at 11:08 AM, Nachi Ueno <nachi at ntti3.com> wrote:
>> >> Hi Jeremy
>> >>
>> >> Don't you think it is burden for operators if we should choose correct
>> >> combination of config for multiple nodes even if we have chef and
>> >> puppet?
>> >>
>> >> If we have some constraint or dependency in configurations, such logic
>> >> should be in openstack source code.
>> >> We can solve this issue if we have a standard way to know the config
>> >> value of other process in the other host.
>> >>
>> >> Something like this.
>> >> self.conf.host('host1').firewall_driver
>> >>
>> >> Then we can have a chef/or file baed config backend code for this for
>> >> example.
>> >>
>> >> Best
>> >> Nachi
>> >>
>> >>
>> >> 2014/1/9 Jeremy Hanmer <jeremy at dreamhost.com>:
>> >>> +1 to Jay.  Existing tools are both better suited to the job and work
>> >>> quite well in their current state.  To address Nachi's first example,
>> >>> there's nothing preventing a Nova node in Chef from reading Neutron's
>> >>> configuration (either by using a (partial) search or storing the
>> >>> necessary information in the environment rather than in roles).  I
>> >>> assume Puppet offers the same.  Please don't re-invent this hugely
>> >>> complicated wheel.
>> >>>
>> >>> On Thu, Jan 9, 2014 at 10:28 AM, Jay Pipes <jaypipes at gmail.com> wrote:
>> >>>> On Thu, 2014-01-09 at 10:23 +0100, Flavio Percoco wrote:
>> >>>>> 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.
>> >>>>
>> >>>> Hi Nati and Flavio!
>> >>>>
>> >>>> So, I'm -1 on this idea, just because I think it belongs in the realm
>> >>>> of
>> >>>> configuration management tooling (Chef/Puppet/Salt/Ansible/etc).
>> >>>> Those
>> >>>> tools are built to manage multiple configuration files and changes in
>> >>>> them. Adding a config server would dramatically change the way that
>> >>>> configuration management tools would interface with OpenStack
>> >>>> services.
>> >>>> Instead of managing the config file templates as all of the tools
>> >>>> currently do, the tools would need to essentially need to forego the
>> >>>> tried-and-true INI files and instead write a bunch of code in order
>> >>>> to
>> >>>> deal with REST API set/get operations for changing configuration
>> >>>> data.
>> >>>>
>> >>>> In summary, while I agree that OpenStack services have an absolute
>> >>>> TON
>> >>>> of configurability -- for good and bad -- there are ways to improve
>> >>>> the
>> >>>> usability of configuration without changing the paradigm that most
>> >>>> configuration management tools expect. One such example is having
>> >>>> include.d/ support -- similar to the existing oslo.cfg module's
>> >>>> support
>> >>>> for a --config-dir, but more flexible and more like what other open
>> >>>> source programs (like Apache) have done for years.
>> >>>>
>> >>>> All the best,
>> >>>> -jay
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> 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
>>
>> _______________________________________________
>> 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
>