Open Stack

During the Austin summit, there was a discussion in the QA meetings
about the future of Neutron's support in DevStack. It's been an ongoing
effort, and I'd like to step back and give everyone a view of the Big
Picture.

https://etherpad.openstack.org/p/newton-qa-devstack-roadmap

A year ago at the NYC QA midcycle, consensus was reached that in order
to get Neutron to become the default deployment model for Devstack and
finally deprecate Nova-Network, some grunt work would need to be done to
clean up the DevStack code.

Dean wrote about the experience in his blog:

http://hackstack.org/x/blog/2015/03/30/qa-code-sprint

>DevStack's Neutron code is in bad shape. It has been continually
>updated by many people who do not understand the Big Picture. I blame
>myself for not staying on top of this code and allowing it to diverge
>from the rest of DevStack's style and implementation. Other Sean found
>a number of inconsistencies in variable names and uses as he tried to
>get the single interface work done and we came to the inevitable
>conclusion that it was time to start over.

So we did.

https://review.openstack.org/168438

The new lib/neutron is an attempt to only have the *bare minimum*
configured for either an OVS or Linux Bridge deployment of Neutron. My
strategy was - start from scratch and build up enough Neutron
configuration to get everything to launch, and have the network plumbed
correctly. Everything else was left on the cutting room floor.

There are still some things that I did for the sake of expediency, that
I am sure will need to be improved in the future. However, the code is
very close to completion - there's still some work that needs to be
done, but I see the light at the end of the tunnel.

For anything that isn't ML2 based, or the LB or OVS agent, Dean and I
share this view:

> But what about the plugins? What about the advanced services? What
> about the vendors? I can't do it all at once. The first priority is to
> get a 'minimum viable Neutron' configuration to use as the default.
> The old code was renamed not removed, and exactly zero of the
> configuration variables and service names have changed. Nothing should
> be directly importing lib/neutron* so that change is handled in
> DevStack and Grenade already. After we have working linuxbridge and
> ovs configurations we can look at what else needs to be included.

Sean Dague and I have also been kicking around some ideas about adding
another hook to the DevStack plugin contract so that DevStack plugins
that do network things have a chance to create networks and wire
everything during installation and configuration, as part of a DevStack
plugin call.

The basic reasoning for this is, the current lib/neutron-legacy has tons
of knobs for plugging veths into things, creating provider networks,
etc.. - those things are very specific to a deployment or networking
type, so they should be moved into a plugin so they don't gunk up the
main code path and also avoid trampling one another (like they do
today).

The current lib/neutron weighs in around 500 lines of code, and the l3
setup code (which was the nastiest) is 300 lines, split out into a
separate file. Partially to allow other plugins to call this code, and
partially because of a divide-and-conquer strategy I am employing for
the refactor.

If you haven't read my post about eliminating the DevStack layer, this
is also part of my thought process for the refactor, and how to support
other configurations in DevStack.

http://lists.openstack.org/pipermail/openstack-dev/2016-April/091764.html

So, take a look at what I've done so far, take it for a spin, and if you
have any thoughts or ideas please share them! 

-- 
Sean M. Collins