openstack/neutron
Code Issues Proposed changes

stadium: Propose kuryr as an independent project.

Browse Source 
This patch adds an additional piece of criteria for Neutron sub-projects.
Projects that interface with Neutron on REST API boundaries only should
probably be separate.  We propose Kuryr be split out based on this criteria.
We also document why Octavia stays for now.

Change-Id: Ic161409f6d1ca2efb623d9c7c2797d158a8094df
Signed-off-by: Russell Bryant <rbryant@redhat.com>
This commit is contained in:
Russell Bryant 2016-02-04 16:40:24 -05:00
parent 846a528735
commit 4cb1f9d578
2 changed files with 29 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/source/policies/neutron-teams.rst
View File

@ -108,10 +108,6 @@ updating the core review team for the sub-project's repositories.
| +---------------------------+----------------------+
| | Gal Sagie | gsagie |
+------------------------+---------------------------+----------------------+
| kuryr | Antoni Segura Puimedon | apuimedo |
| +---------------------------+----------------------+
| | Gal Sagie | gsagie |
+------------------------+---------------------------+----------------------+
| networking-bgpvpn | Mathieu Rohon | matrohon |
| +---------------------------+----------------------+
| | Thomas Morin | tmorin |

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

@ -95,6 +95,9 @@ repository if needed.
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.
Official Sub-Project List
-------------------------
@ -137,8 +140,6 @@ functionality.
+===============================+=======================+
| dragonflow_ | core |
+-------------------------------+-----------------------+
| kuryr_ | docker |
+-------------------------------+-----------------------+
| networking-bagpipe_ | ml2 |
+-------------------------------+-----------------------+
| networking-bgpvpn_ | vpn |
@ -187,6 +188,8 @@ capabilities of Neutron, the Neutron API, or a combination of both.
+-------------------------------+-----------------------+
| Name | Functionality |
+===============================+=======================+
| kuryr_ | docker |
+-------------------------------+-----------------------+
| networking-ale-omniswitch_ | ml2 |
+-------------------------------+-----------------------+
| networking-arista_ | ml2,l3 |
@ -222,6 +225,30 @@ capabilities of Neutron, the Neutron API, or a combination of both.
| vmware-nsx_ | core |
+-------------------------------+-----------------------+
Project Teams FAQ
~~~~~~~~~~~~~~~~~
**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 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