On Nov 18, 2014, at 5:31 PM, Mark McClain <m...@mcclain.xyz> wrote:
> All-
>
> Over the last several months, the members of the Networking Program have been
> discussing ways to improve the management of our program. When the Quantum
> project was initially launched, we envisioned a combined service that
> included all things network related. This vision served us well in the early
> days as the team mostly focused on building out layers 2 and 3; however,
> we’ve run into growth challenges as the project started building out layers 4
> through 7. Initially, we thought that development would float across all
> layers of the networking stack, but the reality is that the development
> concentrates around either layer 2 and 3 or layers 4 through 7. In the last
> few cycles, we’ve also discovered that these concentrations have different
> velocities and a single core team forces one to match the other to the
> detriment of the one forced to slow down.
>
> Going forward we want to divide the Neutron repository into two separate
> repositories lead by a common Networking PTL. The current mission of the
> program will remain unchanged [1]. The split would be as follows:
>
> Neutron (Layer 2 and 3)
> - Provides REST service and technology agnostic abstractions for layer 2 and
> layer 3 services.
>
> Neutron Advanced Services Library (Layers 4 through 7)
> - A python library which is co-released with Neutron
> - The advance service library provides controllers that can be configured to
> manage the abstractions for layer 4 through 7 services.
>
> Mechanics of the split:
> - Both repositories are members of the same program, so the specs repository
> would continue to be shared during the Kilo cycle. The PTL and the drivers
> team will retain approval responsibilities they now share.
> - The split would occur around Kilo-1 (subject to coordination of the Infra
> and Networking teams). The timing is designed to enable the proposed REST
> changes to land around the time of the December development sprint.
> - The core team for each repository will be determined and proposed by Kyle
> Mestery for approval by the current core team.
> - The Neutron Server and the Neutron Adv Services Library would be co-gated
> to ensure that incompatibilities are not introduced.
> - The Advance Service Library would be an optional dependency of Neutron, so
> integrated cross-project checks would not be required to enable it during
> testing.
> - The split should not adversely impact operators and the Networking program
> should maintain standard OpenStack compatibility and deprecation cycles.
>
> This proposal to divide into two repositories achieved a strong consensus at
> the recent Paris Design Summit and it does not conflict with the current
> governance model or any proposals circulating as part of the ‘Big Tent’
> discussion.
>
> Kyle and mark
>
> [1]
> https://git.openstack.org/cgit/openstack/governance/plain/reference/programs.yaml
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
There would not be a service or REST API associated with the Advanced Services
code base? Would the REST API to talk to those services be part of the Neutron
repository?
Doug
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
