openstack/neutron
Code Issues Proposed changes

Revisit the Stadium section of the developer guide

Browse Source 
This patch updates this section to reflect what was agreed on
and sealed in [1]. More iterations will happen as we learn
how effectively the process works.

[1] I689d765fe88ed244e2f6116d0a7d7e4b4f03d08b

Change-Id: I82c35a474a2eccdecafa446b825daa2b8992180f
This commit is contained in:
Armando Migliaccio 2016-06-29 17:57:13 -07:00
parent 58316f7a8c
commit 21235f02c1
4 changed files with 309 additions and 687 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

290
doc/source/stadium/governance.rst Normal file
View File

@ -0,0 +1,290 @@
..
Licensed under the Apache License, Version 2.0 (the "License"); you may
not use this file except in compliance with the License. You may obtain
a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations
under the License.
Convention for heading levels in Neutron devref:
======= Heading 0 (reserved for the title in a document)
------- Heading 1
~~~~~~~ Heading 2
+++++++ Heading 3
''''''' Heading 4
(Avoid deeper levels because they do not render well.)
Stadium Governance
==================
Background
----------
Neutron grew to become a big monolithic codebase, and its core team had a
tough time making progress on a number of fronts, like adding new
features, ensuring stability, etc. During the Kilo timeframe, a
decomposition effort started, where the codebase got disaggregated into
separate repos, like the `high level services <http://specs.openstack.org/openstack/neutron-specs/specs/kilo/services-split.html>`_,
and the various third-party solutions for `L2 and L3 services <http://specs.openstack.org/openstack/neutron-specs/specs/kilo/core-vendor-decomposition.html>`_,
and the Stadium was officially born.
These initiatives enabled the various individual teams in charge of the
smaller projects the opportunity to iterate faster and reduce the time to
feature. This has been due to the increased autonomy and implicit trust model
that made the lack of oversight of the PTL and the Neutron drivers/core team
acceptable for a small number of initiatives. When the proposed `arrangement <https://review.openstack.org/#/c/175952/>`_
allowed projects to be `automatically <http://git.openstack.org/cgit/openstack/governance/commit/?id=321a020cbcaada01976478ea9f677ebb4df7bd6d>`_
enlisted as a Neutron project based simply on description, and desire for
affiliation, the number of projects included in the Stadium started to grow
rapidly, which created a number of challenges for the PTL and the drivers
team.
In fact, it became harder and harder to ensure consistency in the APIs,
architecture, design, implementation and testing of the overarching project;
all aspects of software development, like documentation, integration, release
management, maintainance, and upgrades started to being neglected for some
projects and that led to some unhappy experiences.
The point about uniform APIs is particularly important, because the Neutron
platform is so flexible that a project can take a totally different turn in
the way it exposes functionality, that it is virtually impossible for the
PTL and the drivers team to ensure that good API design principles are being
followed over time. In a situation where each project is on its own, that
might be acceptable, but allowing independent API evolution while still under
the Neutron umbrella is counterproductive.
These challenges led the Neutron team to find a better balance between autonomy
and consistency and lay down criteria that more clearly identify when a project
can be eligible for inclusion in the `Neutron governance <http://governance.openstack.org/reference/projects/neutron.html>`_.
This document describes these criteria, and document the steps involved to
maintain the integrity of the Stadium, and how to ensure this integrity be
maintained over time when modifications to the governance are required.
When is a project considered part of the Stadium?
-------------------------------------------------
In order to be considered part of the Stadium, a project must show a track
record of alignment with the Neutron `core project <http://git.openstack.org/cgit/openstack/neutron>`_.
This means showing proof of adoption of practices as led by the Neutron core
team. Some of these practices are typically already followed by the most
mature OpenStack projects:
* Exhaustive documentation: it is expected that each project will have a
`developer <http://docs.openstack.org/developer/neutron/>`_,
`user/operator <http://docs.openstack.org/mitaka/networking-guide/>`_
and `API <http://developer.openstack.org/api-ref/networking/>`_
documentations available.
* Exhaustive OpenStack CI coverage: unit, functional, and tempest coverage
using OpenStack CI (upstream) resources so that `Grafana <http://grafana.openstack.org/dashboard/db/neutron-failure-rate>`_
and `OpenStack Health <http://status.openstack.org/openstack-health/#/>`_
support is available. Access to CI resources and historical data by the
team is key to ensuring stability and robustness of a project.
In particular, it is of paramount importance to ensure that DB models/migrations
are tested functionally to prevent data inconsistency issues or unexpected
DB logic errors due to schema/models mismatch. For more details, please
look at the following resources:
* https://review.openstack.org/#/c/346091/
* https://review.openstack.org/#/c/346272/
* https://review.openstack.org/#/c/346083/
More Database related information can be found on:
* http://docs.openstack.org/developer/neutron/devref/alembic_migrations.html
* http://docs.openstack.org/developer/neutron/devref/db_layer.html
Bear in mind that many projects have been transitioning their codebase and
tests to fully support Python 3+, and it is important that each Stadium
project supports Python 3+ the same way Neutron core does. For more
information on how to do testing, please refer to the
`Neutron testing documentation testing documentation <http://docs.openstack.org/developer/neutron/devref/development.environment.html#testing-neutron>`_.
* Good release footprint, according to the chosen `release model <http://governance.openstack.org/reference/tags/#release-management-tags>`_.
* Adherence to deprecation and `stable backports policies <http://governance.openstack.org/reference/tags/#stable-maintenance-tags>`_.
* Demonstrated ability to do `upgrades <http://governance.openstack.org/reference/tags/assert_supports-upgrade.html>`_
and/or `rolling upgrades <http://governance.openstack.org/reference/tags/assert_supports-rolling-upgrade.html>`_,
where applicable. This means having grenade support on top of the CI
coverage as described above.
* Client bindings and CLI developed according to the OpenStack Client `plugin model <http://docs.openstack.org/developer/python-openstackclient/plugins.html>`_.
On top of the above mentioned criteria, the following also are taken into
consideration:
* A project must use, adopt and implement open software and technologies.
* A project must integrate with Neutron via one of the supported, advertised
and maintained public Python APIs. REST API does not qualify (the project
python-neutronclient is an exception).
* It adopts neutron-lib (with related hacking rules applied), and has proof
of good decoupling from Neutron core internals.
* It provides an API that adopts API guidelines as set by the Neutron core
team, and that relies on an open implementation.
* It adopts modular interfaces to provide networking services: this means
that L2/7 services are provided in the form of ML2 mech drivers and
service plugins respectively. A service plugin can expose a driver
interface to support multiple backend technologies, and/or adopt the
flavor framework as necessary.
Adding or removing projects to the Stadium
------------------------------------------
When a project is to be considered part of the Stadium, proof of compliance to
the aforementioned practices will have to be demonstrated typically for at
least two OpenStack releases. Application for inclusion is to be considered
only within the first milestone of each OpenStack cycle, which is the time when
the PTL and Neutron team do release planning, and have the most time available
to discuss governance issues.
Projects part of the Neutron Stadium have typically the first milestone to get
their house in order, during which time reassessment happens; if removed, because
of substantial lack of meeting the criteria, a project cannot reapply within
the same release cycle it has been evicted.
The process for proposing a repo into openstack/ and under the Neutron
governance 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
Typically this is a patch that the PTL, in collaboration with the project's
point of contact, will shepherd through the review process. This step is
undertaken once it is clear that all criteria are met. The next section
provides an informal checklist that shows what steps a project needs to
go through in order to enable the PTL and the TC to vote positively on
the proposed inclusion.
Once a project is included, it abides by the Neutron `RFE submission process <http://docs.openstack.org/developer/neutron/policies/blueprints.html>`_,
where specifications to neutron-specs are required for major API as well
as major architectural changes that may require core Neutron platform
enhancements.
Checklist
---------
* How to integrate documentation into docs.o.o: The documentation
website has a section for `project developer documentation <http://docs.openstack.org/developer/openstack-projects.html>`_.
Each project in the Neutron Stadium must have an entry under the
'Networking Sub Projects' section that points to the developer
documentation for the project, available at http://docs.openstack.org/developer/<your-project>/.
This is a two step process that involves the following:
* Build the artefacts: this can be done by following example
https://review.openstack.org/#/c/293399/.
* Publish the artefacts: this can be done by following example
https://review.openstack.org/#/c/216448/.
More information can also be found on the
`project creator guide <http://docs.openstack.org/infra/manual/creators.html#add-link-to-your-developer-documentation>`_.
* How to integrate into Grafana: Grafana is a great tool that provides
the ability to display historical series, like failure rates of
OpenStack CI jobs. A few examples that added dashboards over time are:
* `Neutron <https://review.openstack.org/#/c/278832/>`_.
* `Networking-OVN <https://review.openstack.org/#/c/335791>`_.
* `Networking-Midonet <https://review.openstack.org/#/c/315033>`_.
Any subproject must have a Grafana dashboard that shows failure
rates for at least Gate and Check queues.
* How to integrate into neutron-lib's CI: there are a number of steps
required to integrate with neutron-lib CI and adopt neutron-lib in
general. One step is to validate that neutron-lib master is working
with the master of a given project that uses neutron-lib. For example
`patch <https://review.openstack.org/#/c/338603/>`_ introduced such
support for the Neutron project. Any subproject that wants to do the
same would need to adopt the following few lines:
#. https://review.openstack.org/#/c/338603/4/jenkins/jobs/projects.yaml@4685
#. https://review.openstack.org/#/c/338603/3/zuul/layout.yaml@8501
#. https://review.openstack.org/#/c/338603/4/grafana/neutron.yaml@39
Line 1 and 2 respectively add a job to the periodic queue for the
project, whereas line 3 introduced the failure rate trend for the
periodic job to spot failure spikes etc. Make sure your project has
the following:
#. https://review.openstack.org/#/c/357086/
#. https://review.openstack.org/#/c/359143/
* How to port api-ref over to neutron-lib: to publish the subproject
API reference into the `Networking API guide <http://developer.openstack.org/api-ref/networking/>`_
you must contribute the API documentation into neutron-lib's api-ref
directory as done in the `WADL/REST transition patch <https://review.openstack.org/#/c/327510/>`_.
Once this is done successfully, a link to the subproject API will
show under the published `table of content <https://github.com/openstack/neutron-lib/blob/master/api-ref/source/index.rst>`_.
An RFE bug tracking this effort effectively initiates the request
for Stadium inclusion, where all the aspects as outlined in this
documented are reviewed by the PTL.
* How to port API definitions over the neutron-lib: the most basic
steps to port API definitions over to neutron-lib are demonstrated
in the following patches:
* https://review.openstack.org/#/c/353131/
* https://review.openstack.org/#/c/353132/
The `neutron-lib patch <https://review.openstack.org/#/c/353131/>`_
introduces the elements that define the API, and testing coverage
validates that the resource and actions maps use valid keywords.
API reference documention is provided alongside the definition to
keep everything in one place.
The `neutron patch <https://review.openstack.org/#/c/353132/>`_
uses the Neutron extension framework to plug the API definition
on top of the Neutron API backbone. The change can only merge when
there is a released version of neutron-lib.
* How to integrate into the openstack release: every project in the
Stadium must have release notes. In order to set up release notes,
please see the patches below for an example on how to set up reno:
* https://review.openstack.org/#/c/320904/
* https://review.openstack.org/#/c/243085/
For release documentation related to Neutron, please check the
`Neutron policies document <http://docs.openstack.org/developer/neutron/#neutron-policies>`_.
Once, everything is set up and your project is released, make sure
you see an entry on the release page (e.g. `Newton <http://releases.openstack.org/newton/index.html#other-projects>`_.
Make sure you release according to the project declared release
`model <http://governance.openstack.org/reference/projects/neutron.html#deliverables-and-tags>`_.
* How to port OpenStack Client over to python-neutronclient: client
API bindings and client command line interface support must be
developed in python-neutronclient under `osc module <https://github.com/openstack/python-neutronclient/tree/master/neutronclient/osc/v2>`_.
If your project requires one or both, consider looking at the
following example on how to contribute these two python-neutronclient
according to the OSC framework and guidelines:
* https://review.openstack.org/#/c/340624/
* https://review.openstack.org/#/c/340763/
* https://review.openstack.org/#/c/352653/
More information on how to develop python-openstackclient plugins
can be found on the following links:
* http://docs.openstack.org/developer/python-openstackclient/plugins.html
* http://docs.openstack.org/developer/python-openstackclient/humaninterfaceguide.html
It is worth prefixing the commands being added with the keyword
`network <https://review.openstack.org/#/c/340624/10/setup.cfg>`_ to
avoid potential clash with other commands with similar names. This
is only required if the command object name is highly likely to have
an ambiguous meaning.

0
doc/source/stadium/sub_project_guidelines.rst → doc/source/stadium/guidelines.rst
View File

23
doc/source/stadium/index.rst
View File

@ -16,11 +16,26 @@
Neutron Stadium
================
The Stadium Guide contains information on policies and procedures for the
Neutron Stadium.
This section contains information on policies and procedures for the so called
Neutron Stadium. The Neutron Stadium is the list of projects that show up in the
OpenStack `Governance Document <http://governance.openstack.org/reference/projects/neutron.html>`_.
The list includes projects that the Neutron PTL and core team are directly
involved in, and manage on a day to day basis. To do so, the PTL and team
ensure that common practices and guidelines are followed throughout the Stadium,
for all aspects that pertain software development, from inception, to coding,
testing, documentation and more.
The Stadium is not to be intended as a VIP club for OpenStack networking
projects, or an upper tier within OpenStack. It is simply the list of projects
the Neutron team and PTL claim responsibility for when producing Neutron
deliverables throughout the release `cycles <https://github.com/openstack/releases>`_.
For more details on the Stadium, and what it takes for a project to be
considered an integral part of the Stadium, please read on.
.. toctree::
:maxdepth: 3
sub_projects
sub_project_guidelines
governance
guidelines

683
doc/source/stadium/sub_projects.rst
View File

@ -1,683 +0,0 @@
..
Licensed under the Apache License, Version 2.0 (the "License"); you may
not use this file except in compliance with the License. You may obtain
a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations
under the License.
Convention for heading levels in Neutron devref:
======= Heading 0 (reserved for the title in a document)
------- Heading 1
~~~~~~~ Heading 2
+++++++ Heading 3
''''''' Heading 4
(Avoid deeper levels because they do not render well.)
Neutron Stadium
===============
Introduction
------------
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 <http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#neutron-teams>`_,
or that are affiliated to Neutron via an integration point made available
by the core pluggable framework.
Demystifying the mission
------------------------
The Neutron `mission <http://governance.openstack.org/reference/projects/neutron.html#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.
Inclusion Process
-----------------
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:
http://governance.openstack.org/reference/tags/
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.
http://git.openstack.org/cgit/openstack/governance/commit/?id=321a020cbcaada01976478ea9f677ebb4df7bd6d
In order to create a project, in case it does not exist, follow steps
as explained in:
http://docs.openstack.org/infra/manual/creators.html
Responsibilities
----------------
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 <sub_project_guidelines.html>`_.
Inclusion Criteria
------------------
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.
http://governance.openstack.org/reference/new-projects-requirements.html
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.
* Neutron stays quite busy developing and maintaining open source
implementations for features. Any sub-project that serves as an interface to
proprietary technology should most likely be a separate project team. This
imposes a barrier on access to the technology for dev/test and CI integration.
* If the project only interacts with Neutron on REST API boundaries (client of
Neutron's API, or Neutron is a client of its API), it should probably be a
separate project. python-neutronclient is an obvious exception here.
* The area of functionality of a sub-project should be taken into consideration.
The closer the functionality is to the base functionality implemented in
openstack/neutron, the more likely it makes sense under the Neutron project
team. Conversely, something "higher" in the stack considered an optional
advanced service is more likely to make sense as an independent project.
This is subject to change as the Neutron project evolves and continues to
explore the boundaries that work best for the project.
* OpenStack project teams are based around both technology and groups of people.
If a sub-project is directly driven by a subset of members of the Neutron team,
with the wider approval of the Neutron team, then it makes sense to retain it
under the Neutron project team. Conversely, a project that was developed
without oversight or engagement of any of the Neutron members cannot qualify.
For the sake of this criterion, a member of the team is a known (core or not)
contributor with a substantial track record of Neutron development.
Official Sub-Project List
-------------------------
The official source of all repositories that are a part of Neutron or another
official OpenStack project team is here:
http://governance.openstack.org/reference/projects/neutron.html
We list the Neutron repositories, as well as other Neutron affiliated projects
here to provide references and note the functionality they provide.
Functionality legend
~~~~~~~~~~~~~~~~~~~~
- base: the base Neutron platform;
- bgp: BGP dynamic routing service plugin;
- client: API client implementation;
- core: a monolithic plugin that can implement API at multiple layers L3-L7;
- dashboard: Horizon dashboard integration;
- docker: a Docker network plugin that uses Neutron to provide networking services to Docker containers;
- fw: a Firewall service plugin;
- intent: a service plugin that provides a declarative API to realize networking;
- ipam: an IP address management driver;
- l2: a Layer 2 service;
- l3: a Layer 3 service plugin;
- lb: a Load Balancer service plugin;
- ml2: an ML2 mechanism driver;
- pd: prefix delegation;
- sfc: traffic steering based on traffic classification;
- vpn: a VPN service plugin;
Neutron projects
~~~~~~~~~~~~~~~~
This table shows the list of official Neutron repositories and their
functionality.
+-------------------------------+-----------------------+
| Name | Functionality |
+===============================+=======================+
| 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_ | ml2,l3 |
+-------------------------------+-----------------------+
| networking-sfc_ | sfc |
+-------------------------------+-----------------------+
| neutron_ | base,l2,ml2,core,l3 |
+-------------------------------+-----------------------+
| neutron-dynamic-routing_ | bgp |
+-------------------------------+-----------------------+
| neutron-fwaas_ | fw |
+-------------------------------+-----------------------+
| neutron-lbaas_ | lb,dashboard |
| neutron-lbaas-dashboard_ | |
| octavia_ | |
+-------------------------------+-----------------------+
| neutron-lib_ | base |
+-------------------------------+-----------------------+
| neutron-vpnaas_ | vpn |
+-------------------------------+-----------------------+
| python-neutronclient_ | client |
+-------------------------------+-----------------------+
| python-neutron-pd-driver_ | pd |
+-------------------------------+-----------------------+
Affiliated projects
~~~~~~~~~~~~~~~~~~~
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 |
+===============================+=======================+
| dragonflow_ | core |
+-------------------------------+-----------------------+
| 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-fortinet_ | ml2,l3,fw |
+-------------------------------+-----------------------+
| networking-fujitsu_ | ml2 |
+-------------------------------+-----------------------+
| networking-hyperv_ | ml2 |
+-------------------------------+-----------------------+
| networking-infoblox_ | ipam |
+-------------------------------+-----------------------+
| networking-mlnx_ | ml2 |
+-------------------------------+-----------------------+
| networking-nec_ | core |
+-------------------------------+-----------------------+
| networking-ovs-dpdk_ | ml2 |
+-------------------------------+-----------------------+
| networking-plumgrid_ | core |
+-------------------------------+-----------------------+
| networking-powervm_ | ml2 |
+-------------------------------+-----------------------+
| networking-vsphere_ | ml2 |
+-------------------------------+-----------------------+
| nuage-openstack-neutron_ | core |
+-------------------------------+-----------------------+
| vmware-nsx_ | core |
+-------------------------------+-----------------------+
Project Teams FAQ
~~~~~~~~~~~~~~~~~
**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.
.. _networking-ale-omniswitch:
ALE Omniswitch
++++++++++++++
* Git: https://git.openstack.org/cgit/openstack/networking-ale-omniswitch
* Launchpad: https://launchpad.net/networking-ale-omniswitch
* PyPI: https://pypi.python.org/pypi/networking-ale-omniswitch
.. _networking-arista:
Arista
++++++
* Git: https://git.openstack.org/cgit/openstack/networking-arista
* Launchpad: https://launchpad.net/networking-arista
* PyPI: https://pypi.python.org/pypi/networking-arista
.. _networking-bagpipe:
BaGPipe
+++++++
* Git: https://git.openstack.org/cgit/openstack/networking-bagpipe
* Launchpad: https://launchpad.net/networking-bagpipe
* PyPI: https://pypi.python.org/pypi/networking-bagpipe
.. _networking-bgpvpn:
BGPVPN
++++++
* Git: https://git.openstack.org/cgit/openstack/networking-bgpvpn
* Launchpad: https://launchpad.net/bgpvpn
* PyPI: https://pypi.python.org/pypi/networking-bgpvpn
.. _networking-bigswitch:
Big Switch Networks
+++++++++++++++++++
* Git: https://git.openstack.org/cgit/openstack/networking-bigswitch
* Launchpad: https://launchpad.net/networking-bigswitch
* PyPI: https://pypi.python.org/pypi/bsnstacklib
.. _networking-brocade:
Brocade
+++++++
* Git: https://git.openstack.org/cgit/openstack/networking-brocade
* Launchpad: https://launchpad.net/networking-brocade
* PyPI: https://pypi.python.org/pypi/networking-brocade
.. _networking-calico:
Calico
++++++
* Git: https://git.openstack.org/cgit/openstack/networking-calico
* Launchpad: https://launchpad.net/networking-calico
* PyPI: https://pypi.python.org/pypi/networking-calico
.. _networking-cisco:
Cisco
+++++
* Git: https://git.openstack.org/cgit/openstack/networking-cisco
* Launchpad: https://launchpad.net/networking-cisco
* PyPI: https://pypi.python.org/pypi/networking-cisco
.. _dragonflow:
DragonFlow
++++++++++
* Git: https://git.openstack.org/cgit/openstack/dragonflow
* Launchpad: https://launchpad.net/dragonflow
* PyPI: https://pypi.python.org/pypi/DragonFlow
.. _networking-edge-vpn:
Edge VPN
++++++++
* Git: https://git.openstack.org/cgit/openstack/networking-edge-vpn
* Launchpad: https://launchpad.net/edge-vpn
.. _networking-fortinet:
Fortinet
++++++++
* Git: https://git.openstack.org/cgit/openstack/networking-fortinet
* Launchpad: https://launchpad.net/networking-fortinet
* PyPI: https://pypi.python.org/pypi/networking-fortinet
.. _networking-fujitsu:
FUJITSU
+++++++
* Git: https://git.openstack.org/cgit/openstack/networking-fujitsu
* Launchpad: https://launchpad.net/networking-fujitsu
* PyPI: https://pypi.python.org/pypi/networking-fujitsu
.. _networking-hyperv:
Hyper-V
+++++++
* Git: https://git.openstack.org/cgit/openstack/networking-hyperv
* Launchpad: https://launchpad.net/networking-hyperv
* PyPI: https://pypi.python.org/pypi/networking-hyperv
.. _networking-infoblox:
Infoblox
++++++++
* Git: https://git.openstack.org/cgit/openstack/networking-infoblox
* Launchpad: https://launchpad.net/networking-infoblox
* PyPI: https://pypi.python.org/pypi/networking-infoblox
.. _kuryr:
Kuryr
+++++
* Git: https://git.openstack.org/cgit/openstack/kuryr/
* Launchpad: https://launchpad.net/kuryr
* PyPI: https://pypi.python.org/pypi/kuryr/
.. _networking-l2gw:
L2 Gateway
++++++++++
* Git: https://git.openstack.org/cgit/openstack/networking-l2gw
* Launchpad: https://launchpad.net/networking-l2gw
* PyPI: https://pypi.python.org/pypi/networking-l2gw
.. _networking-midonet:
MidoNet
+++++++
* Git: https://git.openstack.org/cgit/openstack/networking-midonet
* Launchpad: https://launchpad.net/networking-midonet
* PyPI: https://pypi.python.org/pypi/networking-midonet
.. _networking-mlnx:
Mellanox
++++++++
* Git: https://git.openstack.org/cgit/openstack/networking-mlnx
* Launchpad: https://launchpad.net/networking-mlnx
.. _networking-nec:
NEC
+++
* Git: https://git.openstack.org/cgit/openstack/networking-nec
* Launchpad: https://launchpad.net/networking-nec
* PyPI: https://pypi.python.org/pypi/networking-nec
.. _neutron:
Neutron
+++++++
* Git: https://git.openstack.org/cgit/openstack/neutron
* Launchpad: https://launchpad.net/neutron
.. _python-neutronclient:
Neutron Client
++++++++++++++
* Git: https://git.openstack.org/cgit/openstack/python-neutronclient
* Launchpad: https://launchpad.net/python-neutronclient
* PyPI: https://pypi.python.org/pypi/python-neutronclient
.. _neutron-dynamic-routing:
Neutron Dynamic Routing
+++++++++++++++++++++++
* Git: https://git.openstack.org/cgit/openstack/neutron-dynamic-routing
* Launchpad: https://launchpad.net/neutron
.. _neutron-fwaas:
Neutron FWaaS
+++++++++++++
* Git: https://git.openstack.org/cgit/openstack/neutron-fwaas
* Launchpad: https://launchpad.net/neutron
.. _neutron-lbaas:
Neutron LBaaS
+++++++++++++
* Git: https://git.openstack.org/cgit/openstack/neutron-lbaas
* Launchpad: https://launchpad.net/neutron
.. _neutron-lbaas-dashboard:
Neutron LBaaS Dashboard
+++++++++++++++++++++++
* Git: https://git.openstack.org/cgit/openstack/neutron-lbaas-dashboard
* Launchpad: https://launchpad.net/neutron
.. _neutron-lib:
Neutron Library
+++++++++++++++
* Git: https://git.openstack.org/cgit/openstack/neutron-lib
* Launchpad: https://launchpad.net/neutron
.. _python-neutron-pd-driver:
Neutron Prefix Delegation
+++++++++++++++++++++++++
* Git: https://git.openstack.org/cgit/openstack/python-neutron-pd-driver
* Launchpad: https://launchpad.net/python-neutron-pd-driver
* PyPI: https://pypi.python.org/pypi/python-neutron-pd-driver
.. _neutron-vpnaas:
Neutron VPNaaS
++++++++++++++
* Git: https://git.openstack.org/cgit/openstack/neutron-vpnaas
* Launchpad: https://launchpad.net/neutron
.. _nuage-openstack-neutron:
Nuage
+++++
* Git: https://github.com/nuagenetworks/nuage-openstack-neutron
.. _octavia:
Octavia
+++++++
* Git: https://git.openstack.org/cgit/openstack/octavia
* Launchpad: https://launchpad.net/octavia
* PyPI: https://pypi.python.org/pypi/octavia
.. _networking-odl:
OpenDayLight
++++++++++++
* Git: https://git.openstack.org/cgit/openstack/networking-odl
* Launchpad: https://launchpad.net/networking-odl
* PyPI: https://pypi.python.org/pypi/networking-odl
.. _networking-ofagent:
OpenFlow Agent (ofagent)
++++++++++++++++++++++++
* Git: https://git.openstack.org/cgit/openstack/networking-ofagent
* Launchpad: https://launchpad.net/networking-ofagent
* PyPI: https://pypi.python.org/pypi/networking-ofagent
Note: The networking-ofagent project has been removed in the Newton cycle
and the only stable branch is maintained until its EOL.
.. _networking-onos:
Open Network Operating System (onos)
++++++++++++++++++++++++++++++++++++
* Git: https://git.openstack.org/cgit/openstack/networking-onos
* Launchpad: https://launchpad.net/networking-onos
* PyPI: https://pypi.python.org/pypi/networking-onos
.. _networking-ovn:
Open Virtual Network
++++++++++++++++++++
* Git: https://git.openstack.org/cgit/openstack/networking-ovn
* Launchpad: https://launchpad.net/networking-ovn
* PyPI: https://pypi.python.org/pypi/networking-ovn
.. _networking-ovs-dpdk:
Open DPDK
+++++++++
* Git: https://git.openstack.org/cgit/openstack/networking-ovs-dpdk
* Launchpad: https://launchpad.net/networking-ovs-dpdk
* PyPI: https://pypi.python.org/pypi/networking-ovs-dpdk
.. _networking-plumgrid:
PLUMgrid
++++++++
* Git: https://git.openstack.org/cgit/openstack/networking-plumgrid
* Launchpad: https://launchpad.net/networking-plumgrid
* PyPI: https://pypi.python.org/pypi/networking-plumgrid
.. _networking-powervm:
PowerVM
+++++++
* Git: https://git.openstack.org/cgit/openstack/networking-powervm
* Launchpad: https://launchpad.net/networking-powervm
* PyPI: https://pypi.python.org/pypi/networking-powervm
.. _networking-sfc:
SFC
+++
* Git: https://git.openstack.org/cgit/openstack/networking-sfc
* Launchpad: https://launchpad.net/networking-sfc
* PyPI: https://pypi.python.org/pypi/networking-sfc
.. _networking-vsphere:
vSphere
+++++++
* Git: https://git.openstack.org/cgit/openstack/networking-vsphere
* Launchpad: https://launchpad.net/networking-vsphere
* PyPI: https://pypi.python.org/pypi/networking-vsphere
.. _vmware-nsx:
VMware NSX
++++++++++
* Git: https://git.openstack.org/cgit/openstack/vmware-nsx
* Launchpad: https://launchpad.net/vmware-nsx
* PyPI: https://pypi.python.org/pypi/vmware-nsx