stadium: Add a guideline related to project scope.

This guideline is intended to encourage new "advanced services" projects to
be set up as separate OpenStack project teams.

Change-Id: Ieb2e9efa782f2bcc951139558fbb7eecf3e6a46a
Signed-off-by: Russell Bryant <rbryant@redhat.com>
This commit is contained in:
Russell Bryant 2016-02-09 13:33:49 -05:00
parent 4cb1f9d578
commit fee7642958

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.