As for a migration tool.
Due to model changes and deployment changes between LBaaS v1 and LBaaS v2, I am
in favor for the following process:
1. Download LBaaS v1 information (Tenants, Flavors, VIPs, Pools,
Health Monitors , Members) into some JSON format file(s) 2. Delete LBaaS v1 3.
Uninstall LBaaS v1 4. Install LBaaS v2 5. Import the data from 1 back
over LBaaS v2 (need to allow moving from falvor1-->flavor2, need to
make room to some custom modification for mapping between v1 and v2
models)
What do you think?
-Sam.
-----Original Message-----
From: Fox, Kevin M [mailto:kevin....@pnnl.gov]
Sent: Friday, March 04, 2016 2:06 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
Ok. Thanks for the info.
Kevin
________________________________________
From: Brandon Logan [brandon.lo...@rackspace.com]
Sent: Thursday, March 03, 2016 2:42 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
Just for clarity, V2 did not reuse tables, all the tables it uses are only for
it. The main problem is that v1 and v2 both have a pools resource, but v1 and
v2's pool resource have different attributes. With the way neutron wsgi works,
if both v1 and v2 are enabled, it will combine both sets of attributes into the
same validation schema.
The other problem with v1 and v2 running together was only occurring when the
v1 agent driver and v2 agent driver were both in use at the same time. This
may actually have been fixed with some agent updates in neutron, since that is
common code. It needs to be tested out though.
Thanks,
Brandon
On Thu, 2016-03-03 at 22:14 +0000, Fox, Kevin M wrote:
Just because you had thought no one was using it outside of a PoC doesn't mean
folks aren''t using it in production.
We would be happy to migrate to Octavia. We were planning on doing just that by
running both v1 with haproxy namespace, and v2 with Octavia and then pick off
upgrading lb's one at a time, but the reuse of the v1 tables really was an
unfortunate decision that blocked that activity.
We're still trying to figure out a path forward.
We have an outage window next month. after that, it could be about 6
months before we could try a migration due to production load
picking up for a while. I may just have to burn out all the lb's
switch to v2, then rebuild them by hand in a marathon outage :/
And then there's this thingy that also critically needs fixing:
https://bugs.launchpad.net/neutron/+bug/1457556
Thanks,
Kevin
________________________________________
From: Eichberger, German [german.eichber...@hpe.com]
Sent: Thursday, March 03, 2016 12:47 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
Kevin,
If we are offering a migration tool it would be namespace ->
namespace (or maybe Octavia since [1]) - given the limitations
nobody should be using the namespace driver outside a PoC so I am a
bit confused why customers can't self migrate. With 3rd party Lbs I
would assume vendors proving those scripts to make sure their
particular hardware works with those. If you indeed need a migration
from LBaaS
V1 namespace -> LBaaS V2 namespace/Octavia please file an RfE with
your use case so we can discuss it further...
Thanks,
German
[1] https://review.openstack.org/#/c/286380
From: "Fox, Kevin M" <kevin....@pnnl.gov<mailto:kevin....@pnnl.gov>>
Reply-To: "OpenStack Development Mailing List (not for usage
questions)"
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openst
a
c
k.org>>
Date: Wednesday, March 2, 2016 at 5:17 PM
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openst
a
c
k.org>>
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
no removal without an upgrade path. I've got v1 LB's and there still isn't a
migration script to go from v1 to v2.
Thanks,
Kevin
________________________________
From: Stephen Balukoff
[sbaluk...@bluebox.net<mailto:sbaluk...@bluebox.net>]
Sent: Wednesday, March 02, 2016 4:49 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
I am also on-board with removing LBaaS v1 as early as possible in the Newton
cycle.
On Wed, Mar 2, 2016 at 9:44 AM, Samuel Bercovici
<samu...@radware.com<mailto:samu...@radware.com>> wrote:
Thank you all for your response.
In my opinion given that UI/HEAT will make Mitaka and will have one cycle to
mature, it makes sense to remove LBaaS v1 in Newton.
Do we want do discuss an upgrade process in the summit?
-Sam.
From: Bryan Jones
[mailto:jone...@us.ibm.com<mailto:jone...@us.ibm.com>]
Sent: Wednesday, March 02, 2016 5:54 PM
To:
openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.opensta
c
k
.org>
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
And as for the Heat support, the resources have made Mitaka, with additional
functional tests on the way soon.
blueprint:
https://blueprints.launchpad.net/heat/+spec/lbaasv2-suport
gerrit topic:
https://review.openstack.org/#/q/topic:bp/lbaasv2-suport
BRYAN M. JONES
Software Engineer - OpenStack Development
Phone: 1-507-253-2620<tel:1-507-253-2620>
E-mail: jone...@us.ibm.com<mailto:jone...@us.ibm.com>
----- Original message -----
From: Justin Pomeroy
<jpom...@linux.vnet.ibm.com<mailto:jpom...@linux.vnet.ibm.com>>
To:
openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.opensta
c
k
.org>
Cc:
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are we ready?
Date: Wed, Mar 2, 2016 9:36 AM
As for the horizon support, much of it will make Mitaka. See the blueprint and
gerrit topic:
https://blueprints.launchpad.net/horizon/+spec/horizon-lbaas-v2-ui
https://review.openstack.org/#/q/topic:bp/horizon-lbaas-v2-ui,n,z
- Justin
On 3/2/16 9:22 AM, Doug Wiegley wrote:
Hi,
A few things:
- It's not proposed for removal in Mitaka. That patch is for Newton.
- HEAT and Horizon are planned for Mitaka (see
neutron-lbaas-dashboard for the latter.)
- I don't view this as a "keep or delete" question. If sufficient
folks are interested in maintaining it, there is a third option,
which is that the code can be maintained in a separate repo, by a
separate team (with or without the current core team's blessing.)
No decisions have been made yet, but we are on the cusp of some major
maintenance changes, and two deprecation cycles have passed. Which path forward
is being discussed at today's Octavia meeting, or feedback is of course
welcomed here, in IRC, or anywhere.
Thanks,
doug
On Mar 2, 2016, at 7:06 AM, Samuel Bercovici
<samu...@radware.com<mailto:samu...@radware.com>> wrote:
Hi,
I have just notices the following change:
https://review.openstack.org/#/c/286381 which aims to remove LBaaS v1.
Is this planned for Mitaka or for Newton?
While LBaaS v2 is becoming the default, I think that we should have the
following before we replace LBaaS v1:
1. Horizon Support - was not able to find any real activity on it
2. HEAT Support - will it be ready in Mitaka?
Do you have any other items that are needed before we get rid of LBaaS v1?
-Sam.
____________________________________________________________________
_ _ ____ OpenStack Development Mailing List (not for usage
questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org<mailto:OpenStack-dev-reque
s t @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-requ...@lists.openstack.org?subject:unsubscribe<mailto:
O penstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe<mailto:
O penstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe<http:/
/ O penstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Stephen Balukoff
Principal Technologist
Blue Box, An IBM Company
www.blueboxcloud.com<http://www.blueboxcloud.com>
sbaluk...@blueboxcloud.com<mailto:sbaluk...@blueboxcloud.com>
206-607-0660 x807
____________________________________________________________________
_ _ ____ OpenStack Development Mailing List (not for usage
questions)
Unsubscribe:
openstack-dev-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
