Terrific decision! Thank a lot for all this great work. Edgar
On 5/5/16, 9:12 AM, "Monty Taylor" <mord...@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://urldefense.proofpoint.com/v2/url?u=https-3A__etherpad.openstack.org_p_newton-2Dqa-2Ddevstack-2Droadmap&d=CwICAg&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ&m=rQU0CNTLs59JVaD2xnR4lfhgqi7Bp567V_rp3eglXBU&s=fRKjc7Z8RpVFg2mRBUCannAWvfPenic4UPOIk9Qe3Z8&e= >> >> >> 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: >> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__hackstack.org_x_blog_2015_03_30_qa-2Dcode-2Dsprint&d=CwICAg&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ&m=rQU0CNTLs59JVaD2xnR4lfhgqi7Bp567V_rp3eglXBU&s=ZlxFE_krg9WPuNtByMvCpfRYDpNrU2H6nr-7bBnNDrY&e= >> >> >>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_168438&d=CwICAg&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ&m=rQU0CNTLs59JVaD2xnR4lfhgqi7Bp567V_rp3eglXBU&s=M0LvdXPXlRTXCdEr3sCq4VCoo7pQr7OhD_gv0tHHJf8&e= >> >> >> 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. >> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_pipermail_openstack-2Ddev_2016-2DApril_091764.html&d=CwICAg&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ&m=rQU0CNTLs59JVaD2xnR4lfhgqi7Bp567V_rp3eglXBU&s=WDOcyjDzV45GQClN_e5wsY2QKl5Re8wo0iZSEZ_uHsQ&e= >> >> >> 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. > > >__________________________________________________________________________ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev&d=CwICAg&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ&m=rQU0CNTLs59JVaD2xnR4lfhgqi7Bp567V_rp3eglXBU&s=JuzRDh5lMpuHW5u5P7rSdBORVjhu_g8xFcWa0oETuu8&e= > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
