From 21235f02c1596b615a2d0c200be0c4c539ba5dd4 Mon Sep 17 00:00:00 2001 From: Armando Migliaccio Date: Wed, 29 Jun 2016 17:57:13 -0700 Subject: [PATCH] Revisit the Stadium section of the developer guide 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 --- doc/source/stadium/governance.rst | 290 ++++++++ ..._project_guidelines.rst => guidelines.rst} | 0 doc/source/stadium/index.rst | 23 +- doc/source/stadium/sub_projects.rst | 683 ------------------ 4 files changed, 309 insertions(+), 687 deletions(-) create mode 100644 doc/source/stadium/governance.rst rename doc/source/stadium/{sub_project_guidelines.rst => guidelines.rst} (100%) delete mode 100644 doc/source/stadium/sub_projects.rst diff --git a/doc/source/stadium/governance.rst b/doc/source/stadium/governance.rst new file mode 100644 index 00000000000..c782ec18599 --- /dev/null +++ b/doc/source/stadium/governance.rst @@ -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 `_, +and the various third-party solutions for `L2 and L3 services `_, +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 `_ +allowed projects to be `automatically `_ +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 `_. + +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 `_. +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 `_, + `user/operator `_ + and `API `_ + documentations available. + + * Exhaustive OpenStack CI coverage: unit, functional, and tempest coverage + using OpenStack CI (upstream) resources so that `Grafana `_ + and `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 `_. + + * Good release footprint, according to the chosen `release model `_. + + * Adherence to deprecation and `stable backports policies `_. + + * Demonstrated ability to do `upgrades `_ + and/or `rolling upgrades `_, + 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 `_. + +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 `_, +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 `_. + 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//. + 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 `_. + + * 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 `_. + * `Networking-OVN `_. + * `Networking-Midonet `_. + + 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 `_ 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 `_ + you must contribute the API documentation into neutron-lib's api-ref + directory as done in the `WADL/REST transition patch `_. + Once this is done successfully, a link to the subproject API will + show under the published `table of content `_. + 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 `_ + 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 `_ + 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 `_. + Once, everything is set up and your project is released, make sure + you see an entry on the release page (e.g. `Newton `_. + Make sure you release according to the project declared release + `model `_. + + * 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 `_. + 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 `_ 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. diff --git a/doc/source/stadium/sub_project_guidelines.rst b/doc/source/stadium/guidelines.rst similarity index 100% rename from doc/source/stadium/sub_project_guidelines.rst rename to doc/source/stadium/guidelines.rst diff --git a/doc/source/stadium/index.rst b/doc/source/stadium/index.rst index e17648c25f3..43109ed8257 100644 --- a/doc/source/stadium/index.rst +++ b/doc/source/stadium/index.rst @@ -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 `_. + +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 `_. + +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 diff --git a/doc/source/stadium/sub_projects.rst b/doc/source/stadium/sub_projects.rst deleted file mode 100644 index 643a40d22b4..00000000000 --- a/doc/source/stadium/sub_projects.rst +++ /dev/null @@ -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 `_, -or that are affiliated to Neutron via an integration point made available -by the core pluggable framework. - -Demystifying the mission ------------------------- - -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. - -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 `_. - -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