Open Stack

2014/1/9 Doug Hellmann <doug.hellmann at dreamhost.com>:
>
>
>
> On Thu, Jan 9, 2014 at 3:56 PM, Nachi Ueno <nachi at ntti3.com> wrote:
>>
>> 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.
>
>
> But my point is that you shouldn't be thinking about this as "querying
> configuration settings." The fact that a piece of information one service
> needs is stored in the configuration file of another service is an
> implementation detail. It might move. The name of the option could change.
> The way the value is determined might change.

I agree, but may be definition of "configuration" is different with you.
For me, API and Configurations are all reflection from internal Models.
They are just some ways to configure these models.
If configuration is always some lower implementation parameter for you,
I would say it as Model.

> So don't tie yourself to the configuration setting location and name of
> another service. Ask the service the question you have, and let it provide
> an answer. Make it a specific RPC call, so the input parameters can be
> versioned and the response type can be versioned.

+1 for versioning,
However adding more and more rpc call get system management hard, and
let system unstable.
It  make processes tightly coupled, and it make hard to debug.

We should have single storage of logical models. (nova-api for
compute, and neutron server for networking for example). Then all
service should work to realize logical models.

Nachi


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