<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 22, 2015 at 12:30 PM, Kyle Mestery <span dir="ltr"><<a href="mailto:mestery@mestery.com" target="_blank">mestery@mestery.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Wed, Apr 22, 2015 at 1:19 PM, 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"><span>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></span></blockquote></span><div>Thanks for starting this conversation Russell.<br> <br></div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
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></span></blockquote></div></div></div></div></div></blockquote><div><br></div><div>I think the phrase 'vast majority' is misleading, there are still a lot of projects on stackforge.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
to a larger definition of the OpenStack project. Projects making this<br>
move meet the following criteria as being "one of us":<br>
<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>
</span>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>
<div><div><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>
<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>
</div></div>Note that not all of these are equivalent. This is just a list of<br>
stackforge/networking-*.<br>
<span><br>
In some cases there is a split between code in the Neutron tree and in<br>
</span>this repo. In those cases, a shim is in the Neutron tree, but most of<br>
<span>the code is in the external repo. It's also possible to have all of the<br>
code in the external repo.<br>
<br>
</span>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>
<span><br>
<br>
So, my question is: Where should these repositories live in terms of<br>
</span>OpenStack governance and project teams?<br>
<br>
Here are a few paths I think we could take, along with some of my<br>
initial thoughts on pros/cons.<br>
<span><br>
a) Adopt these as repositories under the Neutron project team.<br>
<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>
</span>the backend team would submit to oversight by the Neutron PTL.<br>
<span><br></span></blockquote></div></div><div>Out of your options proposed, this seems like the most logical one to me. I don't really see this imposing a ton of strain on the existing core reviewer team, because we'll keep whatever core reviewer teams are already in the networking-foo projects.<br> <br></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
There are some other details to work out to ensure expectations are<br>
</span>clearly set for everyone involved. If this is the path that makes<br>
<span>sense, we can work through those as a next step.<br>
<br>
</span>Pros:<br>
+ Seems to be the most natural first choice<br></blockquote></span></div></div></div></blockquote><div><br></div><div>Saying something is your first choice isn't a real benefit. It is implying some sort of benefit but I cannot define what the benefit actually is.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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>
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>
<span><br></span></blockquote></span><div>It's interesting you mention neutron "being a platform", because that's exactly where I want it to go in Liberty as well. To that end, I expect to propose a spec splitting out the reference implementation into a separate git repository under the neutron namespace. This will make Neutron an API/DB layer, which is what it should be. It also means the existing reference implementation is on equal footing with things like OVN, ofagent, midonet, OpenDaylight, OpenContrail, and OpenCarrierPigeon [1].<br><br></div><div>One thing which is worth bringing up in this context is the potential overlap between this implementations. I think having them all under the Neutron project would allow me as PTL and the rest of the team work to combine things when it makes sense.<br></div></div></div></div></blockquote><div><br></div><div>So you are adding what sounds like a fairly non-trivial amount of work to the role of Neutron PTL. Can the role of Neutron PTL take on more work? Making the life of the PTL harder doesn't sound like a step in the right direction.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>Kyle<br></div><div><br>[1] <a href="http://www.faqs.org/rfcs/rfc1149.html" target="_blank">http://www.faqs.org/rfcs/rfc1149.html</a><br> <br></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
b) Let each interested group define a new project team for their backend<br>
code.<br>
<br></span></blockquote></span><div>To be honest, I don't this is a scalable option. I'm involved with 2 of these networking-foo projects, and there is not enough participation so far to warrant an entirely new project, PTL and infra around it. This is just my opinion, but it's an opinion I've taken after having contributed to networking-odl and networking-ovn for the past 5 months.<br></div></div></div></div></blockquote><div><br></div><div>What is the limiting factor here? Doesn't each backend need its own team anyway? How does this scaling bottle neck go away under a)?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> <br></div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
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>
</span>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>
<span><br></span></blockquote></div></div></div></div></div></blockquote><div><br></div><div>While I am a big fan of reducing duplicated work, I am not sure what we gain from 'consistency' here. What problem does it solve?</div><div><br></div><div><br></div><div>If I had a vote on this (which I don't think I do) I would choose b.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
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>
</span>consistent approaches to development process, testing, documentation,<br>
and releases.<br>
<span><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>
</span>project team and meet some set of inclusion criteria).<br>
<div><div><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>
</div></div>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>
<span><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>
</span>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>
<span>project guidelines.<br>
<br>
<br>
What option do you think makes sense? Or is there another option that<br>
should be considered?<br>
<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>
</span>[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></div></div></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>