[openstack-dev] [Neutron] A big tent home for Neutron backend code

Russell Bryant rbryant at redhat.com
Wed Apr 22 18:19:17 UTC 2015


A couple of things I've been working on lately are project governance
issues as a TC member and also implementation of a new virtual
networking alternative with a Neutron driver.  So, naturally I started
thinking about how the Neutron driver code fits in to OpenStack governance.

There are basically two areas with a lot of movement related to this issue.

1) Project governance has moved to a "big tent" model [1].  The vast
majority of projects that used to be in Stackforge are being folded in
to a larger definition of the OpenStack project.  Projects making this
move meet the following criteria as being "one of us":


Official project teams are tracked in this file along with the git repos
they are responsible for:


which is also reflected here:


The TC has also been working through defining a system to help
differentiate efforts by using a set of "tags" [4].  So far, we have
tags describing the release handling for a repository, as well as a tag
for team diversity.  We've also had a lot of discussion about tags to
help describe maturity, but that is still a work in progress.

2) In Neutron, some fairly significant good changes are being made to
help scale the development process.  Advanced services were split out
into their own repos [2].  Most of the plugin and driver code has also
been split out into repos [3].

In terms of project teams, the Neutron team is defined as owning the
following repos:


 - openstack/neutron
 - openstack/neutron-fwaas
 - openstack/neutron-lbaas
 - openstack/neutron-vpnaas
 - openstack/neutron-specs
 - openstack/python-neutronclient

The advanced services split is reflected by the fwaas, lbaas, and vpnaas

We also have a large set of repositories related to Neutron backend code:


 - stackforge/networking-arista
 - stackforge/networking-bagpipe-l2
 - stackforge/networking-bgpvpn
 - stackforge/networking-bigswitch
 - stackforge/networking-brocade
 - stackforge/networking-cisco
 - stackforge/networking-edge-vpn
 - stackforge/networking-hyperv
 - stackforge/networking-ibm
 - stackforge/networking-l2gw
 - stackforge/networking-midonet
 - stackforge/networking-mlnx
 - stackforge/networking-nec
 - stackforge/networking-odl
 - stackforge/networking-ofagent
 - stackforge/networking-ovn
 - stackforge/networking-ovs-dpdk
 - stackforge/networking-plumgrid
 - stackforge/networking-portforwarding
 - stackforge/networking-vsphere

Note that not all of these are equivalent.  This is just a list of

In some cases there is a split between code in the Neutron tree and in
this repo.  In those cases, a shim is in the Neutron tree, but most of
the code is in the external repo.  It's also possible to have all of the
code in the external repo.

There's also a big range of maturity.  Some are quite mature and are
already used in production.  networking-ovn as an example is quite new
and being developed in parallel with OVN in the Open vSwitch project.

So, my question is: Where should these repositories live in terms of
OpenStack governance and project teams?

Here are a few paths I think we could take, along with some of my
initial thoughts on pros/cons.

a) Adopt these as repositories under the Neutron project team.

In this case, I would see them operating with their own review teams as
they do today to avoid imposing additional load on the neutron-core or
neutron-specs-core teams.  However, by being a part of the Neutron team,
the backend team would submit to oversight by the Neutron PTL.

There are some other details to work out to ensure expectations are
clearly set for everyone involved.  If this is the path that makes
sense, we can work through those as a next step.

 + Seems to be the most natural first choice

 - A lot of changes have been made precisely because Neutron has gotten
so big.  A single project team/PTL may not be able to effectively
coordinate all of the additional work.  Maybe the core Neutron project
would be better off focusing on being a platform, and other project
teams organize work on backends.

b) Let each interested group define a new project team for their backend

So, as an example, the group of people working on Neutron integration
with OpenDaylight could propose a new project team that would be a
projects.yaml entry that looks something like:

  ptl: Some Person (ircnick)
  service: OpenDaylight Networking
  mission: >
    To implement Neutron support for the OpenDaylight project.
  url: ...
    - repo: openstack/networking-odl

 + There's no additional load on the Neutron project team and PTL.

 - Having all of these efforts organized under a single project team and
PTL might be better for ensuring some level of collaboration and

c) A single new project team could be created that is led by a single
person to coordinate the sub-teams working on each repo.  In this
scenario, I could see the overall collaboration being around ensuring
consistent approaches to development process, testing, documentation,
and releases.

That would be something like this (note that the project list would be
limited to those who actually want to be included in the official
project team and meet some set of inclusion criteria).

  ptl: Some Person (ircnick)
  service: Networking Backends
  mission: >
    To implement Neutron backend support for various networking
  url: ...
    - openstack/networking-arista
    - openstack/networking-bagpipe-l2
    - openstack/networking-bgpvpn
    - openstack/networking-bigswitch
    - openstack/networking-brocade
    - openstack/networking-cisco
    - openstack/networking-edge-vpn
    - openstack/networking-hyperv
    - openstack/networking-ibm
    - openstack/networking-l2gw
    - openstack/networking-midonet
    - openstack/networking-mlnx
    - openstack/networking-nec
    - openstack/networking-odl
    - openstack/networking-ofagent
    - openstack/networking-ovn
    - openstack/networking-ovs-dpdk
    - openstack/networking-plumgrid
    - openstack/networking-portforwarding
    - openstack/networking-vsphere

 + There's no additional load on the Neutron project team and PTL.
 + Avoids a proliferation of new project teams for each Neutron backend.
 + Puts efforts under a single team and PTL to help facilitate
collaboration and consistency.

 - Some might see this as an unnatural split from Neutron.
 - The same sort of oversight and coordination could potentially happen
with a delegate of the Neutron PTL in the Neutron project team without
making it separate.

d) I suppose the last option is to declare that none of these repos make
sense as an OpenStack project.  It's hard for me to imagine this making
sense except for cases where the teams don't want their work to be
officially included in OpenStack, or they fail to meet our base set of
project guidelines.

What option do you think makes sense?  Or is there another option that
should be considered?

[1] http://www.openstack.org/blog/2015/02/tc-update-project-reform-progress/
[4] http://governance.openstack.org/reference/tags/

Russell Bryant

More information about the OpenStack-dev mailing list