Open Stack

Hi Gary,

All of the answers to your questions are on the FAQ linked in the announcement.

1: If you are already using the Octavia driver or the neutron-lbaas
proxy driver, you are already migrated. We will provide a port
migration tool to migrate the neutron port ownership from
neutron-lbaas if neutron-lbaas was configured to create your VIP ports
for the Octavia driver.  For other drivers we will provide a migration
tool during Rocky. The databases are very similar so migrating from
neutron-lbaas will be fairly straight forward.
2: You are correct that currently there are no vendor drivers for
Octavia.  As you probably know, the new and improved driver interface
specification was merged during Queens (A representative from your
employer contributed to the specification).  We expect over the course
of Rocky vendor drivers will become available. This is part of the
motivation for announcing the start of deprecation.
3: This is in no way like the migration from LBaaS v1 to v2. The
largest reason is the LBaaS v2 API is fully compatible with the
Octavia API (it implements LBaaS v2). We did not change the model. The
current load balancer team can't really talk to the choices made in
the V1 to V2 API migrations.

As I have mentioned in the FAQ and on your patch comments,
neutron-lbaas will be maintained with bug fixes for the duration of
the deprecation cycle, which will be a minimum of two OpenStack
releases.

I am sorry you did not get to participate in the discussions and vote
for the start of the deprecation cycle.  We announced that we were
going to work towards this a year and a half ago in a specification
approved by the neutron cores:
http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html
It has been a major topic at our PTG sessions, summits, and weekly
meetings since then.  The team vote that we are ready to announce was
unanimous at our 1/24/2018 IRC meeting.

I hope you will join us going forward to make this deprecation a
success.  We meet weekly on IRC and will be at the PTG.

Michael

On Mon, Feb 12, 2018 at 4:12 AM, Gary Kotton <gkotton at vmware.com> wrote:
> Hi,
> I have a number of issues with this:
> 1. I do not think that we should mark this as deprecated until we have a clear and working migration patch. Let me give an example. Say I have a user who is using Pike or Queens and has N LBaaS load balancers up and running. What if we upgrade to T and there is no LBaaS, only Octavia. What is the migration path here? Maybe I have missed this and would be happy to learn how this was done.
> 2. I think that none of the load balancing vendors have code in Octavia and this may be a problem (somewhat related to #1). I guess that there is enough warning but this is still concerning
> 3. The migration from V1 to V2 was not successful. So, I have some concerns about going to a new service completely.
> I prefer that we hold off on this until there is a clear picture.
> Thanks
> Gary
>
> On 2/1/18, 9:22 AM, "Andreas Jaeger" <aj at suse.com> wrote:
>
>     On 2018-01-31 22:58, Akihiro Motoki wrote:
>     > I don't think we need to drop translation support NOW (at least for
>     > neutron-lbaas-dashboard).
>     > There might be fixes which affects translation and/or there might be
>     > translation improvements.
>     > I don't think a deprecation means no translation fix any more. It
>     > sounds too aggressive.
>     > Is there any problem to keep translations for them?
>
>     Reading the whole FAQ - since bug fixes are planned, translations can
>     merge back. So, indeed we can keep translation infrastructure set up.
>
>     I recommend to translators to remove neutron-lbaas-dashboard from the
>     priority list,
>
>     Andreas
>
>     > Akihiro
>     >
>     > 2018-02-01 3:28 GMT+09:00 Andreas Jaeger <aj at suse.com>:
>     >> In that case, I suggest to remove translation jobs for these repositories,
>     >>
>     >> Andreas
>     >> --
>     >>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>     >>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>     >>    GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>     >>        HRB 21284 (AG Nürnberg)
>     >>     GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>     >>
>     >>
>     >> __________________________________________________________________________
>     >> 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
>     >
>
>
>     --
>      Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>       SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>        GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>            HRB 21284 (AG Nürnberg)
>         GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
>     __________________________________________________________________________
>     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