Merge "stadium: Propose kuryr as an independent project."
This commit is contained in:
commit
5888f79baf
@ -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 |
|
||||
|
@ -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
|
||||
|
Loading…
Reference in New Issue
Block a user