On Wed, Apr 22, 2015 at 12:30 PM, Kyle Mestery <mest...@mestery.com> wrote:
> On Wed, Apr 22, 2015 at 1:19 PM, 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. >> >> Thanks for starting this conversation Russell. > > >> 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 >> > I think the phrase 'vast majority' is misleading, there are still a lot of projects on stackforge. > to a larger definition of the OpenStack project. Projects making this >> move meet the following criteria as being "one of us": >> >> 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]. >> >> 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? >> >> 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. >> >> 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. >> >> 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. > > >> 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. >> >> Pros: >> + Seems to be the most natural first choice >> > 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. > >> 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. >> >> 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]. > > 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. > 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. > Kyle > > [1] http://www.faqs.org/rfcs/rfc1149.html > > >> b) Let each interested group define a new project team for their backend >> code. >> >> 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. > 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)? > > >> 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. >> >> 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? If I had a vote on this (which I don't think I do) I would choose b. > 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. >> >> 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? >> >> >> [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 > >
__________________________________________________________________________ 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
