[openstack-dev] [neutron][gluon]Gluon project plans

pcarver at paulcarver.us pcarver at paulcarver.us
Mon May 15 14:40:48 UTC 2017

This email is to summarize the contents of several impromptu discussions at
the summit last week for those who weren't present. Obviously anything
anybody writes is going to include their own perspective, but hopefully I've
talked about this in enough detail to enough people that I can do a
reasonably fair job of summarizing.


It can be argued that Gluon represents an alternative to Neutron, but that's
not the intent and the Gluon team doesn't want that to be the case. My
preferred description is that Gluon is a proof of concept that starts from
several different primary design goals and that the best, most cooperative
path forward is to combine the key Gluon ideas and benefits with the
existing strengths of Neutron.


There are three main parts of the Gluon project:

*	Gluon itself - Gluon is a core plugin to Neutron derived as a
subclass of ML2 so that it can provide all ML2 functionality, plus a bit
extra when a VLAN-esque layer 2 broadcast domain is not the correct
semantic, or at least not the cleanest semantic
*	Proton Server - A server similar to if the Neutron server only ran
service plugins without running a core plugin and where each service plugin
is defined in domain specific modeling language rather than as Python code
*	Particle Generator - A sort of "compiler" for the YAML DSL in which
"Protons" are written in order to load the API models into the Proton server


The direction which we would like to take is to begin incorporating these
elements of Gluon into the Neutron project and complying with all of the
Neutron Stadium guidelines.


We will start by positioning the Gluon component itself as an available
choice of Neutron core plugin. I view this a little bit like how Neutron
offers a choice of linuxbridge and OvS drivers. The ML2 and Gluon core
plugins are closely related with Gluon just adding a little extra
functionality. Deployers can continue to use ML2 if they don't care about
the few extra bits that Gluon adds. This is similar to deployers who find
OvS too complicated and want to deploy the simpler linuxbridge to get most,
but not all, of the same functionality. A key goal will be that anything
that works using ML2 as the core plugin should also work when using Gluon as
the core plugin.


The second thing we will do is position Particle Generator as a sort of
"Neutron Service Plugin Generator" which will make the Proton Server
unnecessary since the Neutron Server will act as the host for the service


We'll need to work on improving documentation, but the goal will be to offer
current and future Neutron Service Plugin authors the option of using the
YAML DSL to define new Neutron Service Plugins. This doesn't force any
change, but if the DSL proves easy to use it will offer a possibly faster
way of writing Service Plugins


The YAML models which are parsed by the Particle Generator are similar to
the API definitions in neutron-lib[1] but in YAML rather than a dictionary
in Python syntax. My hope is that we will continue to add to Particle
Generator outputs and in the end state it could produce all of the following
as basically output to "compiling" a YAML model of an API:

*	Neutron Service Plugin
*	Database model and expand/contract migrations
*	API documentation - i.e. end user readable content for [2]
*	OpenStack CLI extension (and neutronclient extension if worthwhile,
but perhaps not since it's deprecated)
*	Heat resources
*	Stretch Goal: Horizon GUI panels if a standard structure can be
devised to map the model to a GUI layout


The fourth part of the Gluon project that doesn't quite fit inside of the
Gluon project is the "shim layers" that map APIs onto specific SDN
controllers. Following the Neutron Service Plugin model, these should live
in the various networking-* repos such as networking-odl, networking-ovn,
etc, including the newly created networking-opencontrail.



[2] https://developer.openstack.org/api-ref/networking/v2/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170515/57b6a007/attachment.html>

More information about the OpenStack-dev mailing list