Open Stack

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 <gkotton at 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 <kevin at benton.pub>
> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
> Date: Wednesday, November 9, 2016 at 11:43 PM
> To: OpenStack List <openstack-dev at 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.Fox at 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. [armamig at 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 <gkotton at 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" <johnsomor at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>