Open Stack

> On May 5, 2016, at 8:57 AM, Sean M. Collins <sean at coreitpro.com> 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

I’d actually suggest just linuxbridge (the install guide default), and make the OVS jobs use whatever mechanism the other plugins will have to use.

Thanks,
doug


> 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
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev