From fee7642958e36a01ea9809a81da3705efca528ff Mon Sep 17 00:00:00 2001 From: Russell Bryant Date: Tue, 9 Feb 2016 13:33:49 -0500 Subject: [PATCH] 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 --- doc/source/stadium/sub_projects.rst | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/doc/source/stadium/sub_projects.rst b/doc/source/stadium/sub_projects.rst index b5a71d5b3b0..ea71bafbe0c 100644 --- a/doc/source/stadium/sub_projects.rst +++ b/doc/source/stadium/sub_projects.rst @@ -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.