Open Stack

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.

Thoughts?

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150422/e5f757a1/attachment.html>