openstack/neutron
Code Issues Proposed changes

Merge "stadium: Add a guideline related to project scope."

Browse Source
This commit is contained in:
Jenkins 2016-02-11 20:16:57 +00:00 committed by Gerrit Code Review
commit 0cf2f2485f
1 changed files with 15 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -98,6 +98,13 @@ repository if needed.
* 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.
Official Sub-Project List
-------------------------
@ -242,6 +249,14 @@ 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.