Open Stack

+1 on sharing/outlining migration script form v1 to v2. It will help lot of teams.

Thanks,
Vivek







On 1/26/16, 6:58 PM, "Kevin Carter" <kevin.carter at RACKSPACE.COM> wrote:

>I know that Neutron LBaaS V1 is still available in Liberty and functional, and at this point I assume its in Mitaka (simply judging the code not the actual functionality). From a production stand point I think its safe to say we can keep supporting the V1 implementation for a while however we'll be stuck once V1 is deprecated should there not be a proper migration path for old and new LBs at that time. 
>
>I'd also echo the request from Kevin for a share on some of the migration scripts that have been made such that we can all benefit from the prior art that has already been created. @Eichberger If not possible to share the "proprietary" scripts outright, maybe we could get an outline of the process / whitepaper on what's been done so we can work on to getting the needful migrations baked into Octavia proper? (/me speaking as someone with no experience in Octavia nor the breath of work that I may be asking for however I am interested in making things better for deployers, operators, developers)
>
>--
>
>Kevin Carter
>IRC: cloudnull
>
>
>________________________________________
>From: Fox, Kevin M <Kevin.Fox at pnnl.gov>
>Sent: Tuesday, January 26, 2016 5:38 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support
>
>Thats very very unfortunate. :/ Lbaas team, (or any other team), please never do this again. :/
>
>so does liberty/mitaka at least support using the old v1? it would be nice to have a different flag day to upgrade the load balancers then the upgrade day to get from kilo to release next...
>
>Any chance you can share your migration scripts? I'm guessing we're not the only two clouds that need to migrate things.
>
>hmm.... Would it be possible to rename the tables to something else and tweak a few lines of code so they could run in parallel? Or is there deeper incompatibility then just the same table schema being interpreted differently?
>
>Thanks,
>Kevin
>________________________________________
>From: Eichberger, German [german.eichberger at hpe.com]
>Sent: Tuesday, January 26, 2016 1:39 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support
>
>Hi,
>
>As Brandon pointed out you can’t run V1 and V2 at the same time because they share the same database tables and interpret columns differently. Hence, at HPE we have some proprietary script which takes the V1 database tables and migrates them to the V2 format. After that the v2 agent based driver will pick it up and create those load balancers.
>
>To migrate agent based driver to Octavia we are thinking self migration since people van use the same (ansible) scripts and point them at Octavia.
>
>Thanks,
>German
>
>
>
>On 1/26/16, 12:40 PM, "Fox, Kevin M" <Kevin.Fox at pnnl.gov> wrote:
>
>>I assumed they couldn't run on the same host, but would work on different hosts. maybe I was wrong?
>>
>>I've got a production cloud that's heavily using v1. Having a flag day where we upgrade all from v1 to v2 might be possible, but will be quite painful. If they can be made to co'exist, that would be substantially better.
>>
>>Thanks,
>>Kevin
>>________________________________________
>>From: Brandon Logan [brandon.logan at RACKSPACE.COM]
>>Sent: Tuesday, January 26, 2016 12:19 PM
>>To: openstack-dev at lists.openstack.org
>>Subject: Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support
>>
>>Oh lbaas versioning was a big deal in the beginning.  Versioning an
>>advanced service is a whole other topic and exposed many "interesting"
>>issues with the neutron extension and service plugin framework.
>>
>>The reason v1 and v2 cannot be run together are mainly to get over an
>>issue we had with the 2 different agents which woudl have caused a much
>>larger refactor.  The v1 OR v2 requirement was basically a hack to get
>>around that.  Now that Octavia is the reference implementation and the
>>default, relaxing this restriction shouldn't cause any problems really.
>>Although, I don't want to 100% guarantee that because it's been a while
>>since I was in that world.
>>
>>If that were relaxed, the v2 agent and v1 agent could still be run at
>>the same time which is something to think about.  Come to think about
>>it, we might want to revisit whether the v2 and v1 agent running
>>together is something that can be easily fixed because many things have
>>improved since then AND my knowledge has obviously improved a lot since
>>that time.
>>
>>Glad yall brought this up.
>>
>>Thanks,
>>Brandon
>>
>>
>>On Tue, 2016-01-26 at 14:07 -0600, Major Hayden wrote:
>>> On 01/26/2016 02:01 PM, Fox, Kevin M wrote:
>>> > I believe lbaas v1 and v2 are different then every other openstack api version in that while you can run v1 and v2 at the same time but they are completely different systems that just share a name. A lb created in v1 doesn't show up in v2 or vis a versa. But being able to enable both at once gives users a migration path. If you don't do this, all their lb's will just disappear when going to octavia. :/
>>>
>>> I tend to agree, but I'm hearing that it's not possible to run both versions concurrently.  Brandon might be able to share a little more about the reasons why.
>>>
>>> --
>>> Major Hayden
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>__________________________________________________________________________
>>OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>__________________________________________________________________________
>>OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev