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

2017-03-15 Thread Syed Armani 
Hello Michael,

Thank you for the assurances regarding neutron-lbaas to octavia migration.

Sometimes, i honestly feel that OpenStack needs somebody who can implement
*a* rule something like  "WE DO NOT BREAK USERSPACE!" rule from linux
kernel community.

Cheers,
Syed

On Fri, Mar 10, 2017 at 10:57 PM, Michael Johnson <johnso...@gmail.com>
wrote:

> Hi Syed,
>
>
>
> To my knowledge the LBaaS team did not create any upgrade plan or tools to
> move load balancers from V1 to V2.  The data model is significantly
> different (and better) with V2 and I suspect that caused some challenges.
>
> I know there was a, as-is, database conversion script contributed by an
> operator/packager that might help someone develop a migration path if their
> deployment wasn’t using one of the incompatible configurations, but that
> would only be one piece to the puzzle.
>
>
>
> Since development beyond security fixes for v1 halted over two releases
> ago and the last of the v1 code will be removed from OpenStack in about 32
> days (mitaka goes EOL 4/10/17) I think it is going to be left to the last
> few folks still running LBaaS v1 to plan their migrations.  Most of the
> LBaaS team from the time of v1 deprecation are no longer on the team so we
> don’t really have folks experienced with v1 available any longer.
>
>
>
> I cannot speak to how hard or easy it would be to create a heat migration
> template to recreate the v1 load balancers under v2.
>
>
>
> Beyond that, I can assure you that the migration from neutron-lbaas to
> octavia will have migration procedures and tools to automate the process.
>
>
>
> Michael
>
>
>
> *From:* Syed Armani [mailto:dce3...@gmail.com]
> *Sent:* Friday, March 10, 2017 1:58 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Neutron][LBaaS][heat] Removing LBaaS v1 -
> are weready?
>
>
>
> Folks,
>
>
>
> I am going to ask the question raised by Zane one more time:
>
>
>
> Is there a migration plan for Heat users who have existing stacks
> containing the v1 resources?
>
>
>
> Cheers,
>
> Syed
>
>
>
> On Thu, Aug 25, 2016 at 7:10 PM, Assaf Muller <as...@redhat.com> wrote:
>
> On Thu, Aug 25, 2016 at 7:35 AM, Gary Kotton <gkot...@vmware.com> wrote:
> > Hi,
> > At the moment it is still not clear to me the upgrade process from V1 to
> V2. The migration script https://review.openstack.org/#/c/289595/ has yet
> to be approved. Does this support all drivers or is this just the default
> reference implementation driver?
>
> The migration script doesn't have a test, so we really have no idea if
> it's going to work.
>
>
> > Are there people still using V1?
> > Thanks
> > Gary
> >
> > On 8/25/16, 4:25 AM, "Doug Wiegley" <doug...@parksidesoftware.com>
> wrote:
> >
> >
> > > On Mar 23, 2016, at 4:17 PM, Doug Wiegley <
> doug...@parksidesoftware.com> wrote:
> > >
> > > Migration script has been submitted, v1 is not going anywhere from
> stable/liberty or stable/mitaka, so it’s about to disappear from master.
> > >
> > > I’m thinking in this order:
> > >
> > > - remove jenkins jobs
> > > - wait for heat to remove their jenkins jobs ([heat] added to this
> thread, so they see this coming before the job breaks)
> > > - remove q-lbaas from devstack, and any references to lbaas v1 in
> devstack-gate or infra defaults.
> > > - remove v1 code from neutron-lbaas
> >
> > FYI, all of the above have completed, and the final removal is in
> the merge queue: https://review.openstack.org/#/c/286381/
> >
> > Mitaka will be the last stable branch with lbaas v1.
> >
> > Thanks,
> > doug
> >
> > >
> > > Since newton is now open for commits, this process is going to get
> started.
> > >
> > > Thanks,
> > > doug
> > >
> > >
> > >
> > >> On Mar 8, 2016, at 11:36 AM, Eichberger, German <
> german.eichber...@hpe.com> wrote:
> > >>
> > >> 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, "Samu

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

2017-03-10 Thread Michael Johnson 
Hi Syed,

 

To my knowledge the LBaaS team did not create any upgrade plan or tools to move 
load balancers from V1 to V2.  The data model is significantly different (and 
better) with V2 and I suspect that caused some challenges.

I know there was a, as-is, database conversion script contributed by an 
operator/packager that might help someone develop a migration path if their 
deployment wasn’t using one of the incompatible configurations, but that would 
only be one piece to the puzzle.

 

Since development beyond security fixes for v1 halted over two releases ago and 
the last of the v1 code will be removed from OpenStack in about 32 days (mitaka 
goes EOL 4/10/17) I think it is going to be left to the last few folks still 
running LBaaS v1 to plan their migrations.  Most of the LBaaS team from the 
time of v1 deprecation are no longer on the team so we don’t really have folks 
experienced with v1 available any longer.

 

I cannot speak to how hard or easy it would be to create a heat migration 
template to recreate the v1 load balancers under v2.

 

Beyond that, I can assure you that the migration from neutron-lbaas to octavia 
will have migration procedures and tools to automate the process.

 

Michael

 

From: Syed Armani [mailto:dce3...@gmail.com] 
Sent: Friday, March 10, 2017 1:58 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron][LBaaS][heat] Removing LBaaS v1 - are 
weready?

 

Folks,

 

I am going to ask the question raised by Zane one more time:

 

Is there a migration plan for Heat users who have existing stacks containing 
the v1 resources?

 

Cheers,

Syed

 

On Thu, Aug 25, 2016 at 7:10 PM, Assaf Muller <as...@redhat.com 
<mailto:as...@redhat.com> > wrote:

On Thu, Aug 25, 2016 at 7:35 AM, Gary Kotton <gkot...@vmware.com 
<mailto:gkot...@vmware.com> > wrote:
> Hi,
> At the moment it is still not clear to me the upgrade process from V1 to V2. 
> The migration script https://review.openstack.org/#/c/289595/ has yet to be 
> approved. Does this support all drivers or is this just the default reference 
> implementation driver?

The migration script doesn't have a test, so we really have no idea if
it's going to work.


> Are there people still using V1?
> Thanks
> Gary
>
> On 8/25/16, 4:25 AM, "Doug Wiegley" <doug...@parksidesoftware.com 
> <mailto:doug...@parksidesoftware.com> > wrote:
>
>
> > On Mar 23, 2016, at 4:17 PM, Doug Wiegley <doug...@parksidesoftware.com 
> <mailto:doug...@parksidesoftware.com> > wrote:
> >
> > Migration script has been submitted, v1 is not going anywhere from 
> stable/liberty or stable/mitaka, so it’s about to disappear from master.
> >
> > I’m thinking in this order:
> >
> > - remove jenkins jobs
> > - wait for heat to remove their jenkins jobs ([heat] added to this 
> thread, so they see this coming before the job breaks)
> > - remove q-lbaas from devstack, and any references to lbaas v1 in 
> devstack-gate or infra defaults.
> > - remove v1 code from neutron-lbaas
>
> FYI, all of the above have completed, and the final removal is in the 
> merge queue: https://review.openstack.org/#/c/286381/
>
> Mitaka will be the last stable branch with lbaas v1.
>
> Thanks,
> doug
>
> >
> > Since newton is now open for commits, this process is going to get 
> started.
> >
> > Thanks,
> > doug
> >
> >
> >
> >> On Mar 8, 2016, at 11:36 AM, Eichberger, German 
> <german.eichber...@hpe.com <mailto:german.eichber...@hpe.com> > wrote:
> >>
> >> 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 
> <mailto:samu...@radware.com> > wrote:
> >>
> >>> So this looks like only a database migration, right?
> >>>
> >>> -Original Message-
> >>> From: Eichberger, German [mailto:german.eichber...@hpe.com 
> <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?
> >>>
> >>

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

2017-03-10 Thread Syed Armani 
Folks,

I am going to ask the question raised by Zane one more time:

Is there a migration plan for Heat users who have existing stacks
containing the v1 resources?

Cheers,
Syed

On Thu, Aug 25, 2016 at 7:10 PM, Assaf Muller  wrote:

> On Thu, Aug 25, 2016 at 7:35 AM, Gary Kotton  wrote:
> > Hi,
> > At the moment it is still not clear to me the upgrade process from V1 to
> V2. The migration script https://review.openstack.org/#/c/289595/ has yet
> to be approved. Does this support all drivers or is this just the default
> reference implementation driver?
>
> The migration script doesn't have a test, so we really have no idea if
> it's going to work.
>
> > Are there people still using V1?
> > Thanks
> > Gary
> >
> > On 8/25/16, 4:25 AM, "Doug Wiegley" 
> wrote:
> >
> >
> > > On Mar 23, 2016, at 4:17 PM, Doug Wiegley <
> doug...@parksidesoftware.com> wrote:
> > >
> > > Migration script has been submitted, v1 is not going anywhere from
> stable/liberty or stable/mitaka, so it’s about to disappear from master.
> > >
> > > I’m thinking in this order:
> > >
> > > - remove jenkins jobs
> > > - wait for heat to remove their jenkins jobs ([heat] added to this
> thread, so they see this coming before the job breaks)
> > > - remove q-lbaas from devstack, and any references to lbaas v1 in
> devstack-gate or infra defaults.
> > > - remove v1 code from neutron-lbaas
> >
> > FYI, all of the above have completed, and the final removal is in
> the merge queue: https://review.openstack.org/#/c/286381/
> >
> > Mitaka will be the last stable branch with lbaas v1.
> >
> > Thanks,
> > doug
> >
> > >
> > > Since newton is now open for commits, this process is going to get
> started.
> > >
> > > Thanks,
> > > doug
> > >
> > >
> > >
> > >> On Mar 8, 2016, at 11:36 AM, Eichberger, German <
> german.eichber...@hpe.com> wrote:
> > >>
> > >> 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" 
> 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" 
> 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"

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

2016-08-25 Thread Assaf Muller 
On Thu, Aug 25, 2016 at 7:35 AM, Gary Kotton  wrote:
> Hi,
> At the moment it is still not clear to me the upgrade process from V1 to V2. 
> The migration script https://review.openstack.org/#/c/289595/ has yet to be 
> approved. Does this support all drivers or is this just the default reference 
> implementation driver?

The migration script doesn't have a test, so we really have no idea if
it's going to work.

> Are there people still using V1?
> Thanks
> Gary
>
> On 8/25/16, 4:25 AM, "Doug Wiegley"  wrote:
>
>
> > On Mar 23, 2016, at 4:17 PM, Doug Wiegley 
>  wrote:
> >
> > Migration script has been submitted, v1 is not going anywhere from 
> stable/liberty or stable/mitaka, so it’s about to disappear from master.
> >
> > I’m thinking in this order:
> >
> > - remove jenkins jobs
> > - wait for heat to remove their jenkins jobs ([heat] added to this 
> thread, so they see this coming before the job breaks)
> > - remove q-lbaas from devstack, and any references to lbaas v1 in 
> devstack-gate or infra defaults.
> > - remove v1 code from neutron-lbaas
>
> FYI, all of the above have completed, and the final removal is in the 
> merge queue: https://review.openstack.org/#/c/286381/
>
> Mitaka will be the last stable branch with lbaas v1.
>
> Thanks,
> doug
>
> >
> > Since newton is now open for commits, this process is going to get 
> started.
> >
> > Thanks,
> > doug
> >
> >
> >
> >> On Mar 8, 2016, at 11:36 AM, Eichberger, German 
>  wrote:
> >>
> >> 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"  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"  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"  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 
>

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

2016-08-25 Thread Gary Kotton 
Hi,
At the moment it is still not clear to me the upgrade process from V1 to V2. 
The migration script https://review.openstack.org/#/c/289595/ has yet to be 
approved. Does this support all drivers or is this just the default reference 
implementation driver?
Are there people still using V1? 
Thanks
Gary

On 8/25/16, 4:25 AM, "Doug Wiegley"  wrote:


> On Mar 23, 2016, at 4:17 PM, Doug Wiegley  
wrote:
> 
> Migration script has been submitted, v1 is not going anywhere from 
stable/liberty or stable/mitaka, so it’s about to disappear from master.
> 
> I’m thinking in this order:
> 
> - remove jenkins jobs
> - wait for heat to remove their jenkins jobs ([heat] added to this 
thread, so they see this coming before the job breaks)
> - remove q-lbaas from devstack, and any references to lbaas v1 in 
devstack-gate or infra defaults.
> - remove v1 code from neutron-lbaas

FYI, all of the above have completed, and the final removal is in the merge 
queue: https://review.openstack.org/#/c/286381/

Mitaka will be the last stable branch with lbaas v1.

Thanks,
doug

> 
> Since newton is now open for commits, this process is going to get 
started.
> 
> Thanks,
> doug
> 
> 
> 
>> On Mar 8, 2016, at 11:36 AM, Eichberger, German 
 wrote:
>> 
>> 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"  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"  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"  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

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

2016-08-24 Thread Doug Wiegley 

> On Mar 23, 2016, at 4:17 PM, Doug Wiegley  
> wrote:
> 
> Migration script has been submitted, v1 is not going anywhere from 
> stable/liberty or stable/mitaka, so it’s about to disappear from master.
> 
> I’m thinking in this order:
> 
> - remove jenkins jobs
> - wait for heat to remove their jenkins jobs ([heat] added to this thread, so 
> they see this coming before the job breaks)
> - remove q-lbaas from devstack, and any references to lbaas v1 in 
> devstack-gate or infra defaults.
> - remove v1 code from neutron-lbaas

FYI, all of the above have completed, and the final removal is in the merge 
queue: https://review.openstack.org/#/c/286381/

Mitaka will be the last stable branch with lbaas v1.

Thanks,
doug

> 
> Since newton is now open for commits, this process is going to get started.
> 
> Thanks,
> doug
> 
> 
> 
>> On Mar 8, 2016, at 11:36 AM, Eichberger, German  
>> wrote:
>> 
>> 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"  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"  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"  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

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

2016-03-28 Thread Zane Bitter 

On 23/03/16 17:44, Fox, Kevin M wrote:

Can someone verify the code in the review is complete enough to do a full 
migration? Any steps missing or not documented?

Is heat going to want to support v1 resources longer then neutron does? Its 
kind of nice to be able to run a newer dashboard/heat against an older 
something else.


More importantly, is there a migration plan for Heat users who have 
existing stacks containing the v1 resources?



Thanks,
Kevin

From: Doug Wiegley [doug...@parksidesoftware.com]
Sent: Wednesday, March 23, 2016 2:17 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][heat] Removing LBaaS v1 - are 
weready?

Migration script has been submitted, v1 is not going anywhere from 
stable/liberty or stable/mitaka, so it’s about to disappear from master.

I’m thinking in this order:

- remove jenkins jobs
- wait for heat to remove their jenkins jobs ([heat] added to this thread, so 
they see this coming before the job breaks)
- remove q-lbaas from devstack, and any references to lbaas v1 in devstack-gate 
or infra defaults.
- remove v1 code from neutron-lbaas

Since newton is now open for commits, this process is going to get started.

Thanks,
doug




On Mar 8, 2016, at 11:36 AM, Eichberger, German <german.eichber...@hpe.com> 
wrote:

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 an

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

2016-03-24 Thread Adrian Otto 


> On Mar 24, 2016, at 7:48 AM, Hongbin Lu <hongbin...@huawei.com> wrote:
> 
> 
> 
>> -Original Message-
>> From: Assaf Muller [mailto:as...@redhat.com]
>> Sent: March-24-16 9:24 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Neutron][LBaaS][heat] Removing LBaaS v1 -
>> are weready?
>> 
>> On Thu, Mar 24, 2016 at 1:48 AM, Takashi Yamamoto
>> <yamam...@midokura.com> wrote:
>>> On Thu, Mar 24, 2016 at 6:17 AM, Doug Wiegley
>>> <doug...@parksidesoftware.com> wrote:
>>>> Migration script has been submitted, v1 is not going anywhere from
>> stable/liberty or stable/mitaka, so it’s about to disappear from master.
>>>> 
>>>> I’m thinking in this order:
>>>> 
>>>> - remove jenkins jobs
>>>> - wait for heat to remove their jenkins jobs ([heat] added to this
>>>> thread, so they see this coming before the job breaks)
>>> 
>>> magnum is relying on lbaasv1.  (with heat)
>> 
>> Is there anything blocking you from moving to v2?
> 
> A ticket was created for that: 
> https://blueprints.launchpad.net/magnum/+spec/migrate-to-lbaas-v2 . It will 
> be picked up by contributors once it is approved. Please give us sometimes to 
> finish the work.

Approved.

>>>> - remove q-lbaas from devstack, and any references to lbaas v1 in
>> devstack-gate or infra defaults.
>>>> - remove v1 code from neutron-lbaas
>>>> 
>>>> Since newton is now open for commits, this process is going to get
>> started.
>>>> 
>>>> Thanks,
>>>> doug
>>>> 
>>>> 
>>>> 
>>>>> On Mar 8, 2016, at 11:36 AM, Eichberger, German
>> <german.eichber...@hpe.com> wrote:
>>>>> 
>>>>> 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
>&g

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

2016-03-24 Thread Hongbin Lu 


> -Original Message-
> From: Assaf Muller [mailto:as...@redhat.com]
> Sent: March-24-16 9:24 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron][LBaaS][heat] Removing LBaaS v1 -
> are weready?
> 
> On Thu, Mar 24, 2016 at 1:48 AM, Takashi Yamamoto
> <yamam...@midokura.com> wrote:
> > On Thu, Mar 24, 2016 at 6:17 AM, Doug Wiegley
> > <doug...@parksidesoftware.com> wrote:
> >> Migration script has been submitted, v1 is not going anywhere from
> stable/liberty or stable/mitaka, so it’s about to disappear from master.
> >>
> >> I’m thinking in this order:
> >>
> >> - remove jenkins jobs
> >> - wait for heat to remove their jenkins jobs ([heat] added to this
> >> thread, so they see this coming before the job breaks)
> >
> > magnum is relying on lbaasv1.  (with heat)
> 
> Is there anything blocking you from moving to v2?

A ticket was created for that: 
https://blueprints.launchpad.net/magnum/+spec/migrate-to-lbaas-v2 . It will be 
picked up by contributors once it is approved. Please give us sometimes to 
finish the work.

> 
> >
> >> - remove q-lbaas from devstack, and any references to lbaas v1 in
> devstack-gate or infra defaults.
> >> - remove v1 code from neutron-lbaas
> >>
> >> Since newton is now open for commits, this process is going to get
> started.
> >>
> >> Thanks,
> >> doug
> >>
> >>
> >>
> >>> On Mar 8, 2016, at 11:36 AM, Eichberger, German
> <german.eichber...@hpe.com> wrote:
> >>>
> >>> 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
> >>

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

2016-03-24 Thread Assaf Muller 
On Thu, Mar 24, 2016 at 1:48 AM, Takashi Yamamoto  wrote:
> On Thu, Mar 24, 2016 at 6:17 AM, Doug Wiegley
>  wrote:
>> Migration script has been submitted, v1 is not going anywhere from 
>> stable/liberty or stable/mitaka, so it’s about to disappear from master.
>>
>> I’m thinking in this order:
>>
>> - remove jenkins jobs
>> - wait for heat to remove their jenkins jobs ([heat] added to this thread, 
>> so they see this coming before the job breaks)
>
> magnum is relying on lbaasv1.  (with heat)

Is there anything blocking you from moving to v2?

>
>> - remove q-lbaas from devstack, and any references to lbaas v1 in 
>> devstack-gate or infra defaults.
>> - remove v1 code from neutron-lbaas
>>
>> Since newton is now open for commits, this process is going to get started.
>>
>> Thanks,
>> doug
>>
>>
>>
>>> On Mar 8, 2016, at 11:36 AM, Eichberger, German  
>>> wrote:
>>>
>>> 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"  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"  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"  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

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

2016-03-23 Thread Takashi Yamamoto 
On Thu, Mar 24, 2016 at 6:17 AM, Doug Wiegley
 wrote:
> Migration script has been submitted, v1 is not going anywhere from 
> stable/liberty or stable/mitaka, so it’s about to disappear from master.
>
> I’m thinking in this order:
>
> - remove jenkins jobs
> - wait for heat to remove their jenkins jobs ([heat] added to this thread, so 
> they see this coming before the job breaks)

magnum is relying on lbaasv1.  (with heat)

> - remove q-lbaas from devstack, and any references to lbaas v1 in 
> devstack-gate or infra defaults.
> - remove v1 code from neutron-lbaas
>
> Since newton is now open for commits, this process is going to get started.
>
> Thanks,
> doug
>
>
>
>> On Mar 8, 2016, at 11:36 AM, Eichberger, German  
>> wrote:
>>
>> 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"  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"  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"  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

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

2016-03-23 Thread Fox, Kevin M 
Can someone verify the code in the review is complete enough to do a full 
migration? Any steps missing or not documented?

Is heat going to want to support v1 resources longer then neutron does? Its 
kind of nice to be able to run a newer dashboard/heat against an older 
something else.

Thanks,
Kevin

From: Doug Wiegley [doug...@parksidesoftware.com]
Sent: Wednesday, March 23, 2016 2:17 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][heat] Removing LBaaS v1 - are 
weready?

Migration script has been submitted, v1 is not going anywhere from 
stable/liberty or stable/mitaka, so it’s about to disappear from master.

I’m thinking in this order:

- remove jenkins jobs
- wait for heat to remove their jenkins jobs ([heat] added to this thread, so 
they see this coming before the job breaks)
- remove q-lbaas from devstack, and any references to lbaas v1 in devstack-gate 
or infra defaults.
- remove v1 code from neutron-lbaas

Since newton is now open for commits, this process is going to get started.

Thanks,
doug



> On Mar 8, 2016, at 11:36 AM, Eichberger, German <german.eichber...@hpe.com> 
> wrote:
>
> 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

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

2016-03-23 Thread Doug Wiegley 
Migration script has been submitted, v1 is not going anywhere from 
stable/liberty or stable/mitaka, so it’s about to disappear from master.

I’m thinking in this order:

- remove jenkins jobs
- wait for heat to remove their jenkins jobs ([heat] added to this thread, so 
they see this coming before the job breaks)
- remove q-lbaas from devstack, and any references to lbaas v1 in devstack-gate 
or infra defaults.
- remove v1 code from neutron-lbaas

Since newton is now open for commits, this process is going to get started.

Thanks,
doug



> On Mar 8, 2016, at 11:36 AM, Eichberger, German  
> wrote:
> 
> 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"  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"  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"  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