Open Stack

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161109/d1e1aadc/attachment.html>