On 22 April 2015 at 11:19, Russell Bryant <rbry...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev