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

Kyle Mestery mestery at mestery.com
Thu Apr 23 01:46:38 UTC 2015


On Wed, Apr 22, 2015 at 7:44 PM, Armando M. <armamig at gmail.com> wrote:

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

IMHO, I'm not sure what the StackForge designation means anymore now that
we have the Big Tent. I obviously also don't have the authority to make the
call on when it goes away however.


>
>> 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])
>
>
Don't forget about the split out of the tree of the reference
implementation, defined here:

https://review.openstack.org/#/c/176501/


> [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?
>
>
I'm not sure they are.


>> 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.
>
>
So, have  you seen this patch:

https://review.openstack.org/#/c/173465/

That patch allows for the creation of new repos without TC approval. Thus,
we can create as many as we want, with approval from the PTL.

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

Yes! I think we rename them, but as 4a below indicates, we also add them as
neutron repositories. We're not changing core teams, we're acknowledging
they are a part of Neutron by their integration, and we'll work them into
the broader Neutron Big Stadium.


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

I think you're thinking of this wrong. By moving under Neutron, yes, they
would be under the authority of the Neutron PTL, but really that just means
they get the benefit of being in the broader ecosystem. Think Big Tent
here. As long as they are not directly implementing a competing API with
pluggable drivers underneath and trying to undermine the existing Neutron
API and they follow the 4 opens, why not open the door?


>
>> 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.
>
> Thoughts?
>
>
That seems interesting, but given the communities stated goals around Big
Tent, it seems to me like affiliation or not, adding these under the
Neutron tent, inside the larger OpenStack Bigger Tent, would be a good
thing.

Thanks,
Kyle


> Thanks,
> Armando
>
>
>>
>>
>> [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
>>
>
>
> __________________________________________________________________________
> 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/6efca2cb/attachment.html>


More information about the OpenStack-dev mailing list