<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 22, 2015 at 7:44 PM, Armando M. <span dir="ltr"><<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">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:1px solid rgb(204,204,204);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></span><div><br>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><span class=""><div> <br></div></span></div></div></div></blockquote><div><br></div><div>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.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><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></div></div></blockquote><div><br></div><div>Don't forget about the split out of the tree of the reference implementation, defined here:<br><br><a href="https://review.openstack.org/#/c/176501/">https://review.openstack.org/#/c/176501/</a><br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>[1a] <a href="https://review.openstack.org/#/c/154736/" target="_blank">https://review.openstack.org/#/c/154736/</a></div><div>[2b] <a href="https://review.openstack.org/#/c/174619/" target="_blank">https://review.openstack.org/#/c/174619/</a></div><div>[3b] <a href="https://review.openstack.org/#/c/173549/" target="_blank">https://review.openstack.org/#/c/173549/</a></div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></div><div>It's my understanding that StackForge projects are bound to the same governance model, or am I mistaken? </div><span class=""><div> </div></span></div></div></div></blockquote><div>I'm not sure they are.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><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></div></div></div></blockquote><div> </div><div>So, have you seen this patch:<br><br><a href="https://review.openstack.org/#/c/173465/">https://review.openstack.org/#/c/173465/</a><br><br></div><div>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.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div></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></div></div></blockquote><div><br></div><div>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.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div></div></div><div>[4a] <a href="https://review.openstack.org/#/c/175954" target="_blank">https://review.openstack.org/#/c/175954</a><br></div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><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><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><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><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Pros:<br>
+ Seems to be the most natural first choice<br></blockquote><div><br></div></span><div>Only on a case by case basis, I don't think that there's a single rule we can apply here.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><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><span class=""><div> </div></span></div></div></div></blockquote><div><br></div><div>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?<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><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 class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></div><div>Not sensible either, for the reasons you pointed out.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><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></div></div></blockquote><div><br></div><div>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.<br><br></div><div>Thanks,<br></div><div>Kyle<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>Thanks,</div><div>Armando</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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><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></span></div><br></div></div>
<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>
<br></blockquote></div><br></div></div>