Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Eichberger, German]

Yes, it’s Database only — though we changed the agent driver in the DB from V1 
to V2 — so if you bring up a V2 with that database it should reschedule all 
your load balancers on the V2 agent driver.

German




On 3/8/16, 3:13 AM, "Samuel Bercovici" <samu...@radware.com> wrote:

>So this looks like only a database migration, right?
>
>-Original Message-
>From: Eichberger, German [mailto:german.eichber...@hpe.com] 
>Sent: Tuesday, March 08, 2016 12:28 AM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>
>Ok, for what it’s worth we have contributed our migration script: 
>https://review.openstack.org/#/c/289595/ — please look at this as a starting 
>point and feel free to fix potential problems…
>
>Thanks,
>German
>
>
>
>
>On 3/7/16, 11:00 AM, "Samuel Bercovici" <samu...@radware.com> wrote:
>
>>As far as I recall, you can specify the VIP in creating the LB so you will 
>>end up with same IPs.
>>
>>-Original Message-
>>From: Eichberger, German [mailto:german.eichber...@hpe.com]
>>Sent: Monday, March 07, 2016 8:30 PM
>>To: OpenStack Development Mailing List (not for usage questions)
>>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>>
>>Hi Sam,
>>
>>So if you have some 3rd party hardware you only need to change the 
>>database (your steps 1-5) since the 3rd party hardware will just keep 
>>load balancing…
>>
>>Now for Kevin’s case with the namespace driver:
>>You would need a 6th step to reschedule the loadbalancers with the V2 
>>namespace driver — which can be done.
>>
>>If we want to migrate to Octavia or (from one LB provider to another) it 
>>might be better to use the following steps:
>>
>>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. Transform the JSON format 
>>file into some scripts which recreate the load balancers with your 
>>provider of choice —
>>
>>6. Run those scripts
>>
>>The problem I see is that we will probably end up with different VIPs 
>>so the end user would need to change their IPs…
>>
>>Thanks,
>>German
>>
>>
>>
>>On 3/6/16, 5:35 AM, "Samuel Bercovici" <samu...@radware.com> wrote:
>>
>>>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
>>>
>>

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Fox, Kevin M]

Does it work with DVR though? Probably would with Octavia since they are just 
vm's.

Thanks,
Kevin

From: Eichberger, German [german.eichber...@hpe.com]
Sent: Monday, March 07, 2016 4:11 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

Hi Kevin,

Floating IP will work in V2 as well :-)

Thanks,
German




On 3/7/16, 2:47 PM, "Fox, Kevin M" <kevin@pnnl.gov> wrote:

>You can attach a floating ip onto a vip. Thats what we've done to work around 
>the issue. Well, at least with v1. never tried it with v2.
>
>Thanks,
>Kevin
>
>From: Samuel Bercovici [samu...@radware.com]
>Sent: Monday, March 07, 2016 11:00 AM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>
>As far as I recall, you can specify the VIP in creating the LB so you will end 
>up with same IPs.
>
>-Original Message-
>From: Eichberger, German [mailto:german.eichber...@hpe.com]
>Sent: Monday, March 07, 2016 8:30 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>
>Hi Sam,
>
>So if you have some 3rd party hardware you only need to change the database 
>(your steps 1-5) since the 3rd party hardware will just keep load balancing…
>
>Now for Kevin’s case with the namespace driver:
>You would need a 6th step to reschedule the loadbalancers with the V2 
>namespace driver — which can be done.
>
>If we want to migrate to Octavia or (from one LB provider to another) it might 
>be better to use the following steps:
>
>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. Transform the JSON format file into 
>some scripts which recreate the load balancers with your provider of choice —
>
>6. Run those scripts
>
>The problem I see is that we will probably end up with different VIPs so the 
>end user would need to change their IPs…
>
>Thanks,
>German
>
>
>
>On 3/6/16, 5:35 AM, "Samuel Bercovici" <samu...@radware.com> wrote:
>
>>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 +, 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 
>&

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Samuel Bercovici]

So this looks like only a database migration, right?

-Original Message-
From: Eichberger, German [mailto:german.eichber...@hpe.com] 
Sent: Tuesday, March 08, 2016 12:28 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

Ok, for what it’s worth we have contributed our migration script: 
https://review.openstack.org/#/c/289595/ — please look at this as a starting 
point and feel free to fix potential problems…

Thanks,
German




On 3/7/16, 11:00 AM, "Samuel Bercovici" <samu...@radware.com> wrote:

>As far as I recall, you can specify the VIP in creating the LB so you will end 
>up with same IPs.
>
>-Original Message-
>From: Eichberger, German [mailto:german.eichber...@hpe.com]
>Sent: Monday, March 07, 2016 8:30 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>
>Hi Sam,
>
>So if you have some 3rd party hardware you only need to change the 
>database (your steps 1-5) since the 3rd party hardware will just keep 
>load balancing…
>
>Now for Kevin’s case with the namespace driver:
>You would need a 6th step to reschedule the loadbalancers with the V2 
>namespace driver — which can be done.
>
>If we want to migrate to Octavia or (from one LB provider to another) it might 
>be better to use the following steps:
>
>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. Transform the JSON format 
>file into some scripts which recreate the load balancers with your 
>provider of choice —
>
>6. Run those scripts
>
>The problem I see is that we will probably end up with different VIPs 
>so the end user would need to change their IPs…
>
>Thanks,
>German
>
>
>
>On 3/6/16, 5:35 AM, "Samuel Bercovici" <samu...@radware.com> wrote:
>
>>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 +, 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

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Samuel Bercovici]

Same with Radware. Hence my proposal.

-Original Message-
From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com] 
Sent: Tuesday, March 08, 2016 3:42 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

Hi German,

>> So if you have some 3rd party hardware you only need to change the 
>> database (your steps 1-5) since the 3rd party hardware will just keep 
>> load balancing…

This is not the case with NetScaler it has to go through a Delete of V1 
followed by Create in V2 if a smooth migration is required. 

Thanks,
Vijay V.
-Original Message-
From: Eichberger, German [mailto:german.eichber...@hpe.com]
Sent: 08 March 2016 00:00
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

Hi Sam,

So if you have some 3rd party hardware you only need to change the database 
(your steps 1-5) since the 3rd party hardware will just keep load balancing…

Now for Kevin’s case with the namespace driver:
You would need a 6th step to reschedule the loadbalancers with the V2 namespace 
driver — which can be done.

If we want to migrate to Octavia or (from one LB provider to another) it might 
be better to use the following steps:

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. Transform the JSON format file into 
some scripts which recreate the load balancers with your provider of choice — 

6. Run those scripts

The problem I see is that we will probably end up with different VIPs so the 
end user would need to change their IPs… 

Thanks,
German



On 3/6/16, 5:35 AM, "Samuel Bercovici" <samu...@radware.com> wrote:

>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 +, 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
>> ___

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Vijay Venkatachalam]

Hi German,

>> So if you have some 3rd party hardware you only need to change the database 
>> (your steps 1-5) since the 3rd party hardware will just keep load balancing…

This is not the case with NetScaler it has to go through a Delete of V1 
followed by Create in V2 if a smooth migration is required. 

Thanks,
Vijay V.
-Original Message-
From: Eichberger, German [mailto:german.eichber...@hpe.com] 
Sent: 08 March 2016 00:00
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

Hi Sam,

So if you have some 3rd party hardware you only need to change the database 
(your steps 1-5) since the 3rd party hardware will just keep load balancing…

Now for Kevin’s case with the namespace driver:
You would need a 6th step to reschedule the loadbalancers with the V2 namespace 
driver — which can be done.

If we want to migrate to Octavia or (from one LB provider to another) it might 
be better to use the following steps:

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. Transform the JSON format file into 
some scripts which recreate the load balancers with your provider of choice — 

6. Run those scripts

The problem I see is that we will probably end up with different VIPs so the 
end user would need to change their IPs… 

Thanks,
German



On 3/6/16, 5:35 AM, "Samuel Bercovici" <samu...@radware.com> wrote:

>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 +, 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,
>>
>

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Eichberger, German]

Hi Kevin,

Floating IP will work in V2 as well :-)

Thanks,
German




On 3/7/16, 2:47 PM, "Fox, Kevin M" <kevin@pnnl.gov> wrote:

>You can attach a floating ip onto a vip. Thats what we've done to work around 
>the issue. Well, at least with v1. never tried it with v2.
>
>Thanks,
>Kevin
>
>From: Samuel Bercovici [samu...@radware.com]
>Sent: Monday, March 07, 2016 11:00 AM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>
>As far as I recall, you can specify the VIP in creating the LB so you will end 
>up with same IPs.
>
>-Original Message-
>From: Eichberger, German [mailto:german.eichber...@hpe.com]
>Sent: Monday, March 07, 2016 8:30 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>
>Hi Sam,
>
>So if you have some 3rd party hardware you only need to change the database 
>(your steps 1-5) since the 3rd party hardware will just keep load balancing…
>
>Now for Kevin’s case with the namespace driver:
>You would need a 6th step to reschedule the loadbalancers with the V2 
>namespace driver — which can be done.
>
>If we want to migrate to Octavia or (from one LB provider to another) it might 
>be better to use the following steps:
>
>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. Transform the JSON format file into 
>some scripts which recreate the load balancers with your provider of choice —
>
>6. Run those scripts
>
>The problem I see is that we will probably end up with different VIPs so the 
>end user would need to change their IPs…
>
>Thanks,
>German
>
>
>
>On 3/6/16, 5:35 AM, "Samuel Bercovici" <samu...@radware.com> wrote:
>
>>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 +, 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 migra

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Fox, Kevin M]

Awesome. Thanks. :)

For the record, most of our lb's were created with heat templates. So as of 
now, deleting them and recreating them will work, I think, but may cause some 
issues if we ever turn on convergence, which is a nice feature

Thanks,
Kevin

From: Eichberger, German [german.eichber...@hpe.com]
Sent: Monday, March 07, 2016 2:27 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

Ok, for what it’s worth we have contributed our migration script: 
https://review.openstack.org/#/c/289595/ — please look at this as a starting 
point and feel free to fix potential problems…

Thanks,
German




On 3/7/16, 11:00 AM, "Samuel Bercovici" <samu...@radware.com> wrote:

>As far as I recall, you can specify the VIP in creating the LB so you will end 
>up with same IPs.
>
>-Original Message-
>From: Eichberger, German [mailto:german.eichber...@hpe.com]
>Sent: Monday, March 07, 2016 8:30 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>
>Hi Sam,
>
>So if you have some 3rd party hardware you only need to change the database 
>(your steps 1-5) since the 3rd party hardware will just keep load balancing…
>
>Now for Kevin’s case with the namespace driver:
>You would need a 6th step to reschedule the loadbalancers with the V2 
>namespace driver — which can be done.
>
>If we want to migrate to Octavia or (from one LB provider to another) it might 
>be better to use the following steps:
>
>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. Transform the JSON format file into 
>some scripts which recreate the load balancers with your provider of choice —
>
>6. Run those scripts
>
>The problem I see is that we will probably end up with different VIPs so the 
>end user would need to change their IPs…
>
>Thanks,
>German
>
>
>
>On 3/6/16, 5:35 AM, "Samuel Bercovici" <samu...@radware.com> wrote:
>
>>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 +, 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 t

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Fox, Kevin M]

You can attach a floating ip onto a vip. Thats what we've done to work around 
the issue. Well, at least with v1. never tried it with v2.

Thanks,
Kevin

From: Samuel Bercovici [samu...@radware.com]
Sent: Monday, March 07, 2016 11:00 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

As far as I recall, you can specify the VIP in creating the LB so you will end 
up with same IPs.

-Original Message-
From: Eichberger, German [mailto:german.eichber...@hpe.com]
Sent: Monday, March 07, 2016 8:30 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

Hi Sam,

So if you have some 3rd party hardware you only need to change the database 
(your steps 1-5) since the 3rd party hardware will just keep load balancing…

Now for Kevin’s case with the namespace driver:
You would need a 6th step to reschedule the loadbalancers with the V2 namespace 
driver — which can be done.

If we want to migrate to Octavia or (from one LB provider to another) it might 
be better to use the following steps:

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. Transform the JSON format file into 
some scripts which recreate the load balancers with your provider of choice —

6. Run those scripts

The problem I see is that we will probably end up with different VIPs so the 
end user would need to change their IPs…

Thanks,
German



On 3/6/16, 5:35 AM, "Samuel Bercovici" <samu...@radware.com> wrote:

>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 +, 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 questi

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Eichberger, German]

Ok, for what it’s worth we have contributed our migration script: 
https://review.openstack.org/#/c/289595/ — please look at this as a starting 
point and feel free to fix potential problems…

Thanks,
German




On 3/7/16, 11:00 AM, "Samuel Bercovici" <samu...@radware.com> wrote:

>As far as I recall, you can specify the VIP in creating the LB so you will end 
>up with same IPs.
>
>-Original Message-
>From: Eichberger, German [mailto:german.eichber...@hpe.com] 
>Sent: Monday, March 07, 2016 8:30 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>
>Hi Sam,
>
>So if you have some 3rd party hardware you only need to change the database 
>(your steps 1-5) since the 3rd party hardware will just keep load balancing…
>
>Now for Kevin’s case with the namespace driver:
>You would need a 6th step to reschedule the loadbalancers with the V2 
>namespace driver — which can be done.
>
>If we want to migrate to Octavia or (from one LB provider to another) it might 
>be better to use the following steps:
>
>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. Transform the JSON format file into 
>some scripts which recreate the load balancers with your provider of choice — 
>
>6. Run those scripts
>
>The problem I see is that we will probably end up with different VIPs so the 
>end user would need to change their IPs… 
>
>Thanks,
>German
>
>
>
>On 3/6/16, 5:35 AM, "Samuel Bercovici" <samu...@radware.com> wrote:
>
>>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 +, 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.la

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Samuel Bercovici]

As far as I recall, you can specify the VIP in creating the LB so you will end 
up with same IPs.

-Original Message-
From: Eichberger, German [mailto:german.eichber...@hpe.com] 
Sent: Monday, March 07, 2016 8:30 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

Hi Sam,

So if you have some 3rd party hardware you only need to change the database 
(your steps 1-5) since the 3rd party hardware will just keep load balancing…

Now for Kevin’s case with the namespace driver:
You would need a 6th step to reschedule the loadbalancers with the V2 namespace 
driver — which can be done.

If we want to migrate to Octavia or (from one LB provider to another) it might 
be better to use the following steps:

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. Transform the JSON format file into 
some scripts which recreate the load balancers with your provider of choice — 

6. Run those scripts

The problem I see is that we will probably end up with different VIPs so the 
end user would need to change their IPs… 

Thanks,
German



On 3/6/16, 5:35 AM, "Samuel Bercovici" <samu...@radware.com> wrote:

>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 +, 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 3

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Eichberger, German]

Hi Sam,

So if you have some 3rd party hardware you only need to change the database 
(your steps 1-5) since the 3rd party hardware will just keep load balancing…

Now for Kevin’s case with the namespace driver:
You would need a 6th step to reschedule the loadbalancers with the V2 namespace 
driver — which can be done.

If we want to migrate to Octavia or (from one LB provider to another) it might 
be better to use the following steps:

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. Transform the JSON format file into some scripts which recreate the load 
balancers with your provider of choice — 

6. Run those scripts

The problem I see is that we will probably end up with different VIPs so the 
end user would need to change their IPs… 

Thanks,
German



On 3/6/16, 5:35 AM, "Samuel Bercovici" <samu...@radware.com> wrote:

>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 +, 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,
>> G

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Samuel Bercovici]

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 +, 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.openstac
> 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.openstac
> 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

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Fox, Kevin M]

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 +, 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.openstack.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.openstack.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.openstack.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-supor

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Brandon Logan]

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 +, 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.openstack.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.openstack.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.openstack.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
> E-mail: jone...@us.ibm.com<mailto:jone...@us.ibm.com>
> 
> 
&g

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Fox, Kevin M]

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

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Eichberger, German]

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.openstack.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.openstack.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.openstack.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
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.openstack.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-requ...@lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Fox, Kevin M]

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]
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.openstack.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
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.openstack.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-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: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<mailto: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://openstack-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.blueboxclo

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Stephen Balukoff]

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>
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]
> *Sent:* Wednesday, March 02, 2016 5:54 PM
> *To:* openstack-dev@lists.openstack.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
>
> *E-mail: *jone...@us.ibm.com
>
>
>
>
>
> - Original message -
> From: Justin Pomeroy <jpom...@linux.vnet.ibm.com>
> To: openstack-dev@lists.openstack.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
> <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?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
>
>


-- 
Stephen Balukoff
Principal Technologist
Blue Box, An IBM Company
www.blueboxcloud.com
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

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Samuel Bercovici]

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]
Sent: Wednesday, March 02, 2016 5:54 PM
To: openstack-dev@lists.openstack.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
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.openstack.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-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: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<mailto: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

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

[Bryan Jones]

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
E-mail: jone...@us.ibm.com
 
 
- Original message -From: Justin Pomeroy To: openstack-dev@lists.openstack.orgCc: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-uihttps://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  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?subject:unsubscribehttp://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:unsubscribehttp://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:unsubscribehttp://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