[openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

Robert Collins robertc at robertcollins.net
Tue Nov 25 01:37:12 UTC 2014


On 19 November 2014 at 11:31, Mark McClain <mark at 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.

Just wondering- have you considered a deeper decomposition? This has
turned up e.g. during discussions in the Ironic context where having
an API driven DHCP environment would be great, but all the virtual
network management of Neutron is irrelevant.

E.g - having a collection of minimal do-one-thing-well APIs with a
common model. More SOA than we are today, but easier to reason about
for individual deployments, and providing an arguably clearer place
for vendors that have entirely different backends for various services
to plug into.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud



More information about the OpenStack-dev mailing list