Open Stack

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<mailto: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<mailto: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<mailto: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<mailto: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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161110/77739564/attachment.html>