Open Stack

On 8 April 2016 at 11:06, Sean Dague <sean at dague.net> wrote:

> On 04/08/2016 12:05 PM, Morales, Victor wrote:
> > Agree, sometimes is hard to figure out what is the Devstack variable
> that will modify the configuration value.
> >
> > There is an effort to categorize the configuration options[1] of some of
> the projects.  I’m wondering if it could be possible to create category or
> field that specifies the Destack variable that changes this configuration
> value.
> >
> > [1]
> https://review.openstack.org/#/c/295543/8/specs/categorized-configuration-options.rst
>
> I really don't think that Devstack should leak that far back into real
> projects.
>
> Devstack variables make a ton of sense when you are communicating a
> higher level construct, and it needs to do some logic on it and possibly
> set multiple things.
>
> Devstack variables that are basically pass through for individual config
> vars aren't really a good idea. We try to -1 them all now. But a lot of
> leaked in.
>
> I think Sean Collins' plan is a good one.
>
>         -Sean
>
>
The plethora of networking-specific config variables is a vestigial
presence of a time where local.conf and the plugin mechanism was not in
place in DevStack. Bear in mind that this is not a Neutron specific
problem: all projects are affected more or less equally.

I 100% agree with SeanD that the proposals of passthrough variables is to
be shot down. Those that are used to tune more than one variable at any
given time are more useful instead, as they reduce the number of moving
parts that will have to go into local.conf.

My understanding of the plan to overhaul the neutron (bloated) layer
present in DevStack being tackled in [1] has always been that this was
about trimming the layer rather than eliminating it altogether. Is this
email a reflection of a desire to change direction? If so, SeanC please
clarify because I am slightly confused.

To the very minimum we'd need to find the right blend of config variables
which (in conjunction with some other *optional* local.conf extra juice)
produce the Neutron configuration files that we have in the gate, namely
OVS, LB and OVS+DVR, with their multi-node variants, and thus allow us to
get happy pass with Grenade/Tempest (if that means skipping some tests so
be it) across all the branches we currently gate against. The rest of the
layer can be stripped to the bare bone, but without it we're basically
gonna have to deal with long local.conf files with entire chunks of agent
files etc. thus making Neutron support for repos like devstack-gate and
project-config rather more painful (I am assuming we're gonna have to use
the new layer/approach at some point?). Bear in mind that the complexity
bubble needs to move/split, it's not just gonna burst and vanish :)

On another note, we'd have to keep in mind neutron_plugins that currently
have a place in the devstack tree and/or that rely on the existing
neutron_legacy bits. What's the plan for those (e.g. networking-[ovn, odl,
...] et al)? Finally, what's the plan for switching in the gate?

Cheers,
Armando

[1] https://review.openstack.org/#/c/168438/


> --
> Sean Dague
> http://dague.net
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20160408/5fbd18e6/attachment.html>