Kevin, Yep, totally understand.
This is not a V3, it is simply moving the API from running under neutron to running under the octavia API process. It will still be the LBaaSv2 API, just a new endpoint (though the old endpoint will work for some time into the future). Michael On Wed, Nov 9, 2016 at 12:28 PM, Fox, Kevin M <kevin....@pnnl.gov> wrote: > Just please don't make this a lbv3 thing that completely breaks > compatibility of existing lb's yet again. If its just an "point url endpoint > from thing like x to thing like y" in one place, thats ok. I still have v1 > lb's in existence though I have to deal with and a backwards incompatible v3 > would just cause me to abandon lbaas all together I think as it would show > the lbaas stuff is just not maintainable. > > Thanks, > Kevin > ________________________________ > From: Armando M. [arma...@gmail.com] > Sent: Wednesday, November 09, 2016 8:05 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS > retrospective and next steps recap > > > > On 9 November 2016 at 05:50, Gary Kotton <gkot...@vmware.com> wrote: >> >> Hi, >> What about neutron-lbaas project? Is this project still alive and kicking >> to the merge is done or are we going to continue to maintain it? I feel like >> we are between a rock and a hard place here. LBaaS is in production and it >> is not clear the migration process. Will Octavia have the same DB models as >> LBaaS or will there be a migration? >> Sorry for the pessimism but I feel that things are very unclear and that >> we cannot even indicate to our community/consumers what to use/expect. >> Thanks >> Gary > > > http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html > >> >> >> On 11/8/16, 1:36 AM, "Michael Johnson" <johnso...@gmail.com> wrote: >> >> Ocata LBaaS retrospective and next steps recap >> ---------------------------------------------------------------------- >> >> This session lightly touched on the work in the newton cycle, but >> primarily focused on planning for the Ocata release and the LBaaS spin >> out of neutron and merge into the octavia project [1]. Notes were >> captured on the etherpad [1]. >> >> The focus of work for Ocata in neutron-lbaas and octavia will be on >> the spin out/merge and not new features. >> >> Work has started on merging neutron-lbaas into the octavia project >> with API sorting/pagination, quota support, keystone integration, >> neutron-lbaas driver shim, and documentation updates. Work is still >> needed for policy support, the API shim to handle capability gaps >> (example: stats are by listener in octavia, but by load balancer in >> neturon-lbaas), neutron api proxy, a database migration script from >> the neutron database to the octavia database for existing non-octavia >> load balancers, and adding the "bug for bug" neutron-lbaas v2 API to >> the octavia API server. >> >> The room agreed that since we will have a shim/proxy in neutron for >> some time, updating the OpenStack client can be deferred to a future >> cycle. >> >> There is a lot of concern about Ocata being a short cycle and the >> amount of work to be done. There is hope that additional resources >> will help out with this task to allow us to complete the spin >> out/merge for Ocata. >> >> We discussed the current state of the active/active topology patches >> and agreed that it is unlikely this will merge in Ocata. There are a >> lot of open comments and work to do on the patches. It appears that >> these patches may have been created against an old release and require >> significant updating. >> >> Finally there was a question about when octavia would implement >> metadata tags. When we dug into the need for the tags we found that >> what was really wanted is a full implementation of the flavors >> framework [3] [4]. Some vendors expressed interest in finishing the >> flavors framework for Octavia. >> >> Thank you to everyone that participated in our design session and >> etherpad. >> >> Michael >> >> [1] >> https://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html >> [2] >> https://etherpad.openstack.org/p/ocata-neutron-octavia-lbaas-session >> [3] >> https://specs.openstack.org/openstack/neutron-specs/specs/mitaka/neutron-flavor-framework-templates.html >> [4] >> https://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-flavor-framework.html >> >> >> __________________________________________________________________________ >> 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 >> >> >> __________________________________________________________________________ >> 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 > > > > __________________________________________________________________________ > 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 > __________________________________________________________________________ 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