The people working on the migration are ensuring API compatibility and are even leaving in a shim on the Neutron side for some time so you don't even have to change endpoints initially. It should be a seamless change.
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/ne >> wton/kill-neutron-lbaas.html >> [2] https://etherpad.openstack.org/p/ocata-neutron-octavia-lbaas >> -session >> [3] https://specs.openstack.org/openstack/neutron-specs/specs/mi >> taka/neutron-flavor-framework-templates.html >> [4] https://specs.openstack.org/openstack/neutron-specs/specs/li >> berty/neutron-flavor-framework.html >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.op >> enstack.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:unsubscrib >> e >> 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
