Hi Gary, The LBaaS DB table contents will be moved into the Octavia database as part of the migration process/tool.
Michael On Wed, Nov 9, 2016 at 11:13 PM, Gary Kotton <gkot...@vmware.com> wrote: > Will the same DB be maintained or will the LBaaS DB be moved to that of > Octavia. I am really concerned about this and I feel that it will cause > production problems. > > > > From: Kevin Benton <ke...@benton.pub> > Reply-To: OpenStack List <openstack-dev@lists.openstack.org> > Date: Wednesday, November 9, 2016 at 11:43 PM > To: OpenStack List <openstack-dev@lists.openstack.org> > > > Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS > retrospective and next steps recap > > > > 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/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 > __________________________________________________________________________ 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