Open Stack

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.

--
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140110/2cfb4d2f/attachment.html>