[openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap

Michael Johnson johnsomor at gmail.com
Wed Nov 9 23:43:50 UTC 2016


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.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
>



More information about the OpenStack-dev mailing list