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 >>> >>>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.openst >>>> a >>>> 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.openst >>>> a >>>> 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.opensta >>>> c >>>> 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.opensta >>>> c >>>> 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-reque >>>> s 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 >__________________________________________________________________________ >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
