Open Stack

On 05/05/2016 10:57 AM, Sean M. Collins wrote:
> 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!

Everything about this is the best thing that has ever happened since the 
dawn of time.