Open Stack

On Thu, May 5, 2016 at 11:12 AM, Monty Taylor <mordred at inaugust.com> wrote:
> 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.
>

<3

>
>
> __________________________________________________________________________
> 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