+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.car...@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....@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.eichber...@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....@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.lo...@rackspace.com] >>Sent: Tuesday, January 26, 2016 12:19 PM >>To: openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >>__________________________________________________________________________ >>OpenStack Development Mailing List (not for usage questions) >>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >>__________________________________________________________________________ >>OpenStack Development Mailing List (not for usage questions) >>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >__________________________________________________________________________ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >__________________________________________________________________________ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >__________________________________________________________________________ >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
