Neutron has grown to be a complex project made of many moving parts. The codebase is the aggregation of smaller projects that, once assembled in a specific configuration, implement one of the many deployment architectures to deliver networking services.
This document explains the inclusion process, and the criteria chosen to select a project for inclusion. It also outlines the lists of projects that are either managed by the Neutron teams, or that are affiliated to Neutron via an integration point made available by the core pluggable framework.
The Neutron mission states that Neutron is all about delivering network services and libraries. Although this has been true for the existence of the project, the project itself has evolved over the years to meet the demands of a growing community of users and developers who have an interest in adopting, building new and leveraging existing network functionality. To continue to stay true to its mission, and yet reduce the management burden, the project transformed itself into a pluggable framework, and a community where interested parties come together to discuss and define APIs and respective implementations that ultimately are delivered on top of the aforementioned pluggable framework. Some of these APIs and implementations are considered to be a part of the Neutron project. For the ones that are not, there is no connotation of _poor_ quality associated with them. Their association, or lack thereof, is simply a reflection of the fact that a good portion of Neutron team feels favorable towards developing, and supporting the project in the wider OpenStack ecosystem.
The process for proposing a repo into openstack/ and under the Neutron project is to propose a patch to the openstack/governance repository. For example, to propose networking-foo, one would add the following entry under Neutron in reference/projects.yaml:
- repo: openstack/networking-foo
tags:
- name: release:independent
For more information about the release:independent tag (and other currently defined tags) see:
The Neutron PTL must approve the change. The TC clarified that once a project has been approved (Neutron in this case), the project can add additional repos without needing TC approval as long as the added repositories are within the existing approved scope of the project.
In order to create a project, in case it does not exist, follow steps as explained in:
All affected repositories already have their own review teams. The sub-team working on the sub-project is entirely responsible for day-to-day development. That includes reviews, bug tracking, and working on testing.
By being included, the project accepts oversight by the TC as a part of being in OpenStack, and also accepts oversight by the Neutron PTL.
It is also assumed the respective review teams will make sure their projects stay in line with current best practices.
As mentioned before, the Neutron PTL must approve the inclusion of each additional repository under the Neutron project. When in doubt, the PTL should consider erring on the side of caution, and keep the project out of the list until more consensus amongst the team can be built or a more favorable assessment can be determined. That evaluation will be initially based on the new project requirements used for all new OpenStack projects for the criteria that is applicable. If there is any question about this, the review should be deferred to the TC as a new OpenStack project team.
Including everything related to Neutron under the Neutron project team has not scaled well, so some Neutron related projects are encouraged to form a new OpenStack project team. The following list of guidelines are not hard rules. There may be exceptions. Instead, they serve as criteria that may influence the decision one way or the other. Sub-projects will be reviewed regularly to see how they meet these criteria.
These criteria are designed around how easy it would be for members of the loosely defined “Neutron team” to jump in and help fix or even take over a given repository if needed.
The official source of all repositories that are a part of Neutron or another official OpenStack project team is here:
We list the Neutron repositories, as well as other Neutron affiliated projects here to provide references and note the functionality they provide.
This table shows the list of official Neutron repositories and their functionality.
| Name | Functionality |
|---|---|
| dragonflow | core |
| networking-bagpipe | ml2 |
| networking-bgpvpn | vpn |
| networking-calico | ml2 |
| networking-l2gw | l2 |
| networking-midonet | core,ml2,l3,lb,fw |
| networking-odl | ml2,l3,lb,fw |
| networking-ofagent | ml2 |
| networking-onos | ml2,l3 |
| networking-ovn | core |
| networking-sfc | sfc |
| neutron | base,l2,ml2,core,l3 |
| neutron-lbaas neutron-lbaas-dashboard octavia | lb,dashboard |
| neutron-fwaas | fw |
| neutron-lib | base |
| neutron-vpnaas | vpn |
| python-neutronclient | client |
| python-neutron-pd-driver | pd |
This table shows the affiliated projects that integrate with Neutron, in one form or another. These projects typically leverage the pluggable capabilities of Neutron, the Neutron API, or a combination of both.
| Name | Functionality |
|---|---|
| kuryr | docker |
| networking-ale-omniswitch | ml2 |
| networking-arista | ml2,l3 |
| networking-bigswitch | ml2,core,l3 |
| networking-brocade | ml2,l3 |
| networking-cisco | core,ml2,l3,fw,vpn |
| networking-edge-vpn | vpn |
| networking-fujitsu | ml2 |
| networking-hyperv | ml2 |
| networking-infoblox | ipam |
| networking-mlnx | ml2 |
| networking-nec | core |
| networking-plumgrid | core |
| networking-powervm | ml2 |
| nuage-openstack-neutron | core |
| networking-ovs-dpdk | ml2 |
| networking-vsphere | ml2 |
| vmware-nsx | core |
Q: When talking about contributor overlap, what is a contributor?
A Neutron contributor is someone who spends some portion of their time helping with all of the things needed to run the Neutron project: bug triage, writing and reviewing blueprints, writing and reviewing code, writing and reviewing documentation, helping debug issues found by users or CI, and more.
Q: Why choose contributor overlap over technical overlap?
Technical overlap, or software qualities, are more difficult to pinpoint and require a more extensive assessment from the PTL and the Neutron team, which in turn has the danger of translating itself into a nearly full-time policing/enforcement job. Wrongdoing will always be spotted, regardless of whichever criteria is applied, and trusting known members of the team to do the right thing should be an adequate safety net to preserve the sanity of Neutron as a whole.
Q: What does a sub-project gain as a part of the Neutron project team?
A project under Neutron is no more an official part of OpenStack than another OpenStack project team. Projects under Neutron share some resources. In particular, they get managed backports, managed releases, managed CVEs, RFEs, bugs, docs and everything that pertain the SDLC of the Neutron end-to-end project.
Q: Why is kuryr a separate project?
Kuryr was started and incubated within the Neutron team. However, it interfaces with Neutron as a client of the Neutron API, so it makes sense to stand as an independent project.
Q: Why are several “advanced service” projects still included under Neutron?
neutron-lbaas, neutron-fwaas, and neutron-vpnaas are all included under the Neutron project team largely for historical reasons. They were originally a part of neutron itself and are still a part of the neutron deliverable in terms of OpenStack governance. Because of the deliverable inclusion, they should really only be considered for a move on a release boundary.
Q: Why is Octavia included under Neutron?
neutron-lbaas, neutron-lbaas-dashboard, and Octavia are all considered a unit. If we split one, we need to split them together. We can’t split these yet, as they are a part of the official “neutron” deliverable. This needs to be done on a release boundary when the lbaas team is ready to do so.