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