<div dir="ltr">Yeah, seriously, thanks a million for this.<div>You are making developers lives wayyyy better!</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-05-05 18:12 GMT+02:00 Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 05/05/2016 10:57 AM, Sean M. Collins wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
During the Austin summit, there was a discussion in the QA meetings<br>
about the future of Neutron's support in DevStack. It's been an ongoing<br>
effort, and I'd like to step back and give everyone a view of the Big<br>
Picture.<br>
<br>
<a href="https://etherpad.openstack.org/p/newton-qa-devstack-roadmap" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/newton-qa-devstack-roadmap</a><br>
<br>
A year ago at the NYC QA midcycle, consensus was reached that in order<br>
to get Neutron to become the default deployment model for Devstack and<br>
finally deprecate Nova-Network, some grunt work would need to be done to<br>
clean up the DevStack code.<br>
<br>
Dean wrote about the experience in his blog:<br>
<br>
<a href="http://hackstack.org/x/blog/2015/03/30/qa-code-sprint" rel="noreferrer" target="_blank">http://hackstack.org/x/blog/2015/03/30/qa-code-sprint</a><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
DevStack's Neutron code is in bad shape. It has been continually<br>
updated by many people who do not understand the Big Picture. I blame<br>
myself for not staying on top of this code and allowing it to diverge<br>
from the rest of DevStack's style and implementation. Other Sean found<br>
a number of inconsistencies in variable names and uses as he tried to<br>
get the single interface work done and we came to the inevitable<br>
conclusion that it was time to start over.<br>
</blockquote>
<br>
So we did.<br>
<br>
<a href="https://review.openstack.org/168438" rel="noreferrer" target="_blank">https://review.openstack.org/168438</a><br>
<br>
The new lib/neutron is an attempt to only have the *bare minimum*<br>
configured for either an OVS or Linux Bridge deployment of Neutron. My<br>
strategy was - start from scratch and build up enough Neutron<br>
configuration to get everything to launch, and have the network plumbed<br>
correctly. Everything else was left on the cutting room floor.<br>
<br>
There are still some things that I did for the sake of expediency, that<br>
I am sure will need to be improved in the future. However, the code is<br>
very close to completion - there's still some work that needs to be<br>
done, but I see the light at the end of the tunnel.<br>
<br>
For anything that isn't ML2 based, or the LB or OVS agent, Dean and I<br>
share this view:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But what about the plugins? What about the advanced services? What<br>
about the vendors? I can't do it all at once. The first priority is to<br>
get a 'minimum viable Neutron' configuration to use as the default.<br>
The old code was renamed not removed, and exactly zero of the<br>
configuration variables and service names have changed. Nothing should<br>
be directly importing lib/neutron* so that change is handled in<br>
DevStack and Grenade already. After we have working linuxbridge and<br>
ovs configurations we can look at what else needs to be included.<br>
</blockquote>
<br>
Sean Dague and I have also been kicking around some ideas about adding<br>
another hook to the DevStack plugin contract so that DevStack plugins<br>
that do network things have a chance to create networks and wire<br>
everything during installation and configuration, as part of a DevStack<br>
plugin call.<br>
<br>
The basic reasoning for this is, the current lib/neutron-legacy has tons<br>
of knobs for plugging veths into things, creating provider networks,<br>
etc.. - those things are very specific to a deployment or networking<br>
type, so they should be moved into a plugin so they don't gunk up the<br>
main code path and also avoid trampling one another (like they do<br>
today).<br>
<br>
The current lib/neutron weighs in around 500 lines of code, and the l3<br>
setup code (which was the nastiest) is 300 lines, split out into a<br>
separate file. Partially to allow other plugins to call this code, and<br>
partially because of a divide-and-conquer strategy I am employing for<br>
the refactor.<br>
<br>
If you haven't read my post about eliminating the DevStack layer, this<br>
is also part of my thought process for the refactor, and how to support<br>
other configurations in DevStack.<br>
<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2016-April/091764.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2016-April/091764.html</a><br>
<br>
So, take a look at what I've done so far, take it for a spin, and if you<br>
have any thoughts or ideas please share them!<br>
</blockquote>
<br></div></div>
Everything about this is the best thing that has ever happened since the dawn of time.<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>