Open Stack

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/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-request at 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-request at 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-request at 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/20161109/f6ab3518/attachment-0001.html>