[openstack-dev] [devstack][neutron] Eliminating the DevStack layer
Matt Kassawara
mkassawara at gmail.com
Mon Apr 11 15:16:24 UTC 2016
Good news... the number of neutron options with a sane default value has
increased significantly in the last couple of releases. If you're looking
at the installation guide, it explicitly configures more options to
override bad values set by distribution packages. For deployment tools,
explicitly configuring certain options prevents surprises if default values
change. Automatic configuration file generation and the release notes
mechanism makes detection of these changes a bit easier, but building
confidence takes time.
On Mon, Apr 11, 2016 at 8:39 AM, Sean M. Collins <sean at coreitpro.com> wrote:
> Armando M. wrote:
> > 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.
>
> As part of the DevStack refactor, I am trying to shrink the amount of
> DevStack configuration variables that are carried around for Neutron.
> That is the part I am trying to eliminate. There must be support for
> Neutron in DevStack, if we ever wish to become the default networking
> project in OpenStack and successfully deprecate nova-network.
>
> > 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 :)
>
> It is my hope that we can start looking at some of these configurations,
> take a look at what puppet or ansible set, and realize that a lot of
> these options could just be defaults instead of making it the job of
> deployment tools to explicitly configure.
>
> > 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?
>
> I think neutron_plugins will eventually be removed. Third party plugins
> like ovn, odl, et al most likely have DevStack plugins that supersede
> the code in neutron_plugins.
>
> For the OVS and LB agents, I think we need to clean them up, and again,
> see what can be configured by default.
>
> --
> Sean M. Collins
>
> __________________________________________________________________________
> 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/20160411/e7fb9c7a/attachment.html>
More information about the OpenStack-dev
mailing list