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

Armando M. armamig at gmail.com
Thu Apr 23 00:44:29 UTC 2015

On 22 April 2015 at 11:19, Russell Bryant <rbryant at redhat.com> wrote:

> Hello!
> 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":

Is it sensible to assume that Stackforge is going away entirely at some
point in the future, and we'll have a single namespace - OpenStack?

> http://governance.openstack.org/reference/new-projects-requirements.html
> Official project teams are tracked in this file along with the git repos
> they are responsible for:
> http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
> which is also reflected here:
> http://governance.openstack.org/reference/projects/
> 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].

This is too still a work in progress. A lot has been achieved during the
Kilo timeframe, but more is still to be done, like the 'lib-ification - if
that's even a word' of Neutron [1a], the split of plugins out of the *aas
drivers [2b], and the rest of the core-vendor-decomp (latest status update
is available in [3b])

[1a] https://review.openstack.org/#/c/154736/
[2b] https://review.openstack.org/#/c/174619/
[3b] https://review.openstack.org/#/c/173549/

> In terms of project teams, the Neutron team is defined as owning the
> following repos:
>   http://governance.openstack.org/reference/projects/neutron.html
>  - 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
> repos.
> We also have a large set of repositories related to Neutron backend code:
>   http://git.openstack.org/cgit/?q=stackforge%2Fnetworking
>  - 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
> stackforge/networking-*.
> 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?

It's my understanding that StackForge projects are bound to the same
governance model, or am I mistaken?

> 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.

I fully understand how this is implemented in, can you elaborate? Would
that translate into something like [4a]? The other concern I have is that
the list is bound to change due to the WIP nature of the work we're going
through, and I wouldn't want to freeze it just yet, as we can't.

Would just renaming the existing repos from stackforge/* to openstack/*
suffice? Do we ask people to submit the new ones to the openstack namespace
from now on? Would that slow down their ability to decompose because the
big tent is not there yet?

[4a] https://review.openstack.org/#/c/175954

> 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.

Not sure why the PTL would need to be officially appointed of an oversight
capacity, especially because some projects are different than others, so
how would we choose?

> 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.

I fear that changing the rules while we play would cause more trouble than
it's worth. I think it's reasonable to converge at some point, but it
sounds like it's early.

> Pros:
>  + Seems to be the most natural first choice

Only on a case by case basis, I don't think that there's a single rule we
can apply here.

> Cons:
>  - 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.

To me this is the major sticking point of this approach. I don't think that
the Neutron PTL makes sense for some of these project and I wouldn't want
to cause fractures into what *is* and *is not* Neutron. I'd rather have a
fair playing field for every networking related project.

> b) Let each interested group define a new project team for their backend
> code.
> 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:
> Neutron-OpenDaylight:
>   ptl: Some Person (ircnick)
>   service: OpenDaylight Networking
>   mission: >
>     To implement Neutron support for the OpenDaylight project.
>   url: ...
>   projects:
>     - repo: openstack/networking-odl
> Pros:
>  + There's no additional load on the Neutron project team and PTL.
> Cons:
>  - Having all of these efforts organized under a single project team and
> PTL might be better for ensuring some level of collaboration and
> consistency.

Some projects can be pretty narrow in scope that I am not sure I see the
need of going fully-fledged here, unless there is a mandate. Furthermore
the PTL might simply be the point of contact rather than one who is leading
a team.

> 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).
> Neutron-Backends:
>   ptl: Some Person (ircnick)
>   service: Networking Backends
>   mission: >
>     To implement Neutron backend support for various networking
>     technologies.
>   url: ...
>   projects:
>     - 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
> Pros:
>  + 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.
> Cons:
>  - 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.

Not sensible either, for the reasons you pointed out.

> 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?

Would it make sense to capture these projects as simply 'affiliated', ie.
with a loose relationship to Neutron, because they use/integrate with
Neutron in some form or another (e.g. having 3rd-party, extending-api,
integrating-via-plugin-model, etc)? Then we could simply consider extending
the projects.yaml to capture this new concept (for Neutron or any other
project) once we defined its ontology.



> [1]
> http://www.openstack.org/blog/2015/02/tc-update-project-reform-progress/
> [2]
> http://specs.openstack.org/openstack/neutron-specs/specs/kilo/services-split.html
> [3]
> http://specs.openstack.org/openstack/neutron-specs/specs/kilo/core-vendor-decomposition.html
> [4] http://governance.openstack.org/reference/tags/
> --
> Russell Bryant
> __________________________________________________________________________
> 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/20150422/e5f757a1/attachment.html>

More information about the OpenStack-dev mailing list