<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 22 April 2015 at 11:19, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hello!<br>
<br>
A couple of things I've been working on lately are project governance<br>
issues as a TC member and also implementation of a new virtual<br>
networking alternative with a Neutron driver. So, naturally I started<br>
thinking about how the Neutron driver code fits in to OpenStack governance.<br>
<br>
There are basically two areas with a lot of movement related to this issue.<br>
<br>
1) Project governance has moved to a "big tent" model [1]. The vast<br>
majority of projects that used to be in Stackforge are being folded in<br>
to a larger definition of the OpenStack project. Projects making this<br>
move meet the following criteria as being "one of us":</blockquote><div><br class="">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?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<a href="http://governance.openstack.org/reference/new-projects-requirements.html" target="_blank">http://governance.openstack.org/reference/new-projects-requirements.html</a><br>
<br>
Official project teams are tracked in this file along with the git repos<br>
they are responsible for:<br>
<br>
<a href="http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml" target="_blank">http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml</a><br>
<br>
which is also reflected here:<br>
<br>
<a href="http://governance.openstack.org/reference/projects/" target="_blank">http://governance.openstack.org/reference/projects/</a><br>
<br>
The TC has also been working through defining a system to help<br>
differentiate efforts by using a set of "tags" [4]. So far, we have<br>
tags describing the release handling for a repository, as well as a tag<br>
for team diversity. We've also had a lot of discussion about tags to<br>
help describe maturity, but that is still a work in progress.<br>
<br>
<br>
2) In Neutron, some fairly significant good changes are being made to<br>
help scale the development process. Advanced services were split out<br>
into their own repos [2]. Most of the plugin and driver code has also<br>
been split out into repos [3].<br></blockquote><div><br></div><div>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])</div><div><br></div><div>[1a] <a href="https://review.openstack.org/#/c/154736/">https://review.openstack.org/#/c/154736/</a></div><div>[2b] <a href="https://review.openstack.org/#/c/174619/">https://review.openstack.org/#/c/174619/</a></div><div>[3b] <a href="https://review.openstack.org/#/c/173549/">https://review.openstack.org/#/c/173549/</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
In terms of project teams, the Neutron team is defined as owning the<br>
following repos:<br>
<br>
<a href="http://governance.openstack.org/reference/projects/neutron.html" target="_blank">http://governance.openstack.org/reference/projects/neutron.html</a><br>
<br>
- openstack/neutron<br>
- openstack/neutron-fwaas<br>
- openstack/neutron-lbaas<br>
- openstack/neutron-vpnaas<br>
- openstack/neutron-specs<br>
- openstack/python-neutronclient<br>
<br>
The advanced services split is reflected by the fwaas, lbaas, and vpnaas<br>
repos.<br>
<br>
We also have a large set of repositories related to Neutron backend code:<br>
<br>
<a href="http://git.openstack.org/cgit/?q=stackforge%2Fnetworking" target="_blank">http://git.openstack.org/cgit/?q=stackforge%2Fnetworking</a><br>
<br>
- stackforge/networking-arista<br>
- stackforge/networking-bagpipe-l2<br>
- stackforge/networking-bgpvpn<br>
- stackforge/networking-bigswitch<br>
- stackforge/networking-brocade<br>
- stackforge/networking-cisco<br>
- stackforge/networking-edge-vpn<br>
- stackforge/networking-hyperv<br>
- stackforge/networking-ibm<br>
- stackforge/networking-l2gw<br>
- stackforge/networking-midonet<br>
- stackforge/networking-mlnx<br>
- stackforge/networking-nec<br>
- stackforge/networking-odl<br>
- stackforge/networking-ofagent<br>
- stackforge/networking-ovn<br>
- stackforge/networking-ovs-dpdk<br>
- stackforge/networking-plumgrid<br>
- stackforge/networking-portforwarding<br>
- stackforge/networking-vsphere<br>
<br>
Note that not all of these are equivalent. This is just a list of<br>
stackforge/networking-*.<br>
<br>
In some cases there is a split between code in the Neutron tree and in<br>
this repo. In those cases, a shim is in the Neutron tree, but most of<br>
the code is in the external repo. It's also possible to have all of the<br>
code in the external repo.<br>
<br>
There's also a big range of maturity. Some are quite mature and are<br>
already used in production. networking-ovn as an example is quite new<br>
and being developed in parallel with OVN in the Open vSwitch project.<br>
<br>
<br>
So, my question is: Where should these repositories live in terms of<br>
OpenStack governance and project teams? </blockquote><div><br></div><div>It's my understanding that StackForge projects are bound to the same governance model, or am I mistaken? </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Here are a few paths I think we could take, along with some of my<br>
initial thoughts on pros/cons.<br>
<br>
a) Adopt these as repositories under the Neutron project team.<br></blockquote><div><br></div><div><div>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. </div><div><br></div><div>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? </div><div> <br></div></div><div>[4a] <a href="https://review.openstack.org/#/c/175954">https://review.openstack.org/#/c/175954</a><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
In this case, I would see them operating with their own review teams as<br>
they do today to avoid imposing additional load on the neutron-core or<br>
neutron-specs-core teams. However, by being a part of the Neutron team,<br>
the backend team would submit to oversight by the Neutron PTL.<br></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
There are some other details to work out to ensure expectations are<br>
clearly set for everyone involved. If this is the path that makes<br>
sense, we can work through those as a next step.<br></blockquote><div><br></div><div><div>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.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Pros:<br>
+ Seems to be the most natural first choice<br></blockquote><div><br></div><div>Only on a case by case basis, I don't think that there's a single rule we can apply here.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Cons:<br>
- A lot of changes have been made precisely because Neutron has gotten<br>
so big. A single project team/PTL may not be able to effectively<br>
coordinate all of the additional work. Maybe the core Neutron project<br>
would be better off focusing on being a platform, and other project<br>
teams organize work on backends.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
b) Let each interested group define a new project team for their backend<br>
code.<br>
<br>
So, as an example, the group of people working on Neutron integration<br>
with OpenDaylight could propose a new project team that would be a<br>
projects.yaml entry that looks something like:<br>
<br>
Neutron-OpenDaylight:<br>
ptl: Some Person (ircnick)<br>
service: OpenDaylight Networking<br>
mission: ><br>
To implement Neutron support for the OpenDaylight project.<br>
url: ...<br>
projects:<br>
- repo: openstack/networking-odl<br>
<br>
Pros:<br>
+ There's no additional load on the Neutron project team and PTL.<br>
<br>
Cons:<br>
- Having all of these efforts organized under a single project team and<br>
PTL might be better for ensuring some level of collaboration and<br>
consistency.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
c) A single new project team could be created that is led by a single<br>
person to coordinate the sub-teams working on each repo. In this<br>
scenario, I could see the overall collaboration being around ensuring<br>
consistent approaches to development process, testing, documentation,<br>
and releases.<br>
<br>
That would be something like this (note that the project list would be<br>
limited to those who actually want to be included in the official<br>
project team and meet some set of inclusion criteria).<br>
<br>
Neutron-Backends:<br>
ptl: Some Person (ircnick)<br>
service: Networking Backends<br>
mission: ><br>
To implement Neutron backend support for various networking<br>
technologies.<br>
url: ...<br>
projects:<br>
- openstack/networking-arista<br>
- openstack/networking-bagpipe-l2<br>
- openstack/networking-bgpvpn<br>
- openstack/networking-bigswitch<br>
- openstack/networking-brocade<br>
- openstack/networking-cisco<br>
- openstack/networking-edge-vpn<br>
- openstack/networking-hyperv<br>
- openstack/networking-ibm<br>
- openstack/networking-l2gw<br>
- openstack/networking-midonet<br>
- openstack/networking-mlnx<br>
- openstack/networking-nec<br>
- openstack/networking-odl<br>
- openstack/networking-ofagent<br>
- openstack/networking-ovn<br>
- openstack/networking-ovs-dpdk<br>
- openstack/networking-plumgrid<br>
- openstack/networking-portforwarding<br>
- openstack/networking-vsphere<br>
<br>
Pros:<br>
+ There's no additional load on the Neutron project team and PTL.<br>
+ Avoids a proliferation of new project teams for each Neutron backend.<br>
+ Puts efforts under a single team and PTL to help facilitate<br>
collaboration and consistency.<br>
<br>
Cons:<br>
- Some might see this as an unnatural split from Neutron.<br>
- The same sort of oversight and coordination could potentially happen<br>
with a delegate of the Neutron PTL in the Neutron project team without<br>
making it separate.<br></blockquote><div><br></div><div>Not sensible either, for the reasons you pointed out.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
d) I suppose the last option is to declare that none of these repos make<br>
sense as an OpenStack project. It's hard for me to imagine this making<br>
sense except for cases where the teams don't want their work to be<br>
officially included in OpenStack, or they fail to meet our base set of<br>
project guidelines.<br>
<br>
<br>
What option do you think makes sense? Or is there another option that<br>
should be considered?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Thoughts?</div><div><br></div><div>Thanks,</div><div>Armando</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
[1] <a href="http://www.openstack.org/blog/2015/02/tc-update-project-reform-progress/" target="_blank">http://www.openstack.org/blog/2015/02/tc-update-project-reform-progress/</a><br>
[2]<br>
<a href="http://specs.openstack.org/openstack/neutron-specs/specs/kilo/services-split.html" target="_blank">http://specs.openstack.org/openstack/neutron-specs/specs/kilo/services-split.html</a><br>
[3]<br>
<a href="http://specs.openstack.org/openstack/neutron-specs/specs/kilo/core-vendor-decomposition.html" target="_blank">http://specs.openstack.org/openstack/neutron-specs/specs/kilo/core-vendor-decomposition.html</a><br>
[4] <a href="http://governance.openstack.org/reference/tags/" target="_blank">http://governance.openstack.org/reference/tags/</a><br>
<span class=""><font color="#888888"><br>
--<br>
Russell Bryant<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br></div></div>