> -----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 > >>>>> 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- > d...@lists.op > >>>>>>> enst > >>>>>>> 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- > d...@lists.op > >>>>>>> enst > >>>>>>> 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- > d...@lists.ope > >>>>>>> nsta > >>>>>>> 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- > d...@lists.ope > >>>>>>> nsta > >>>>>>> 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- > r > >>>>>>> eque s t @lists.openstack.org>?subject:unsubscribe > >>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack- > de > >>>>>>> v > >>>>>>> > >>>>>>> > ________________________________________________________________ > >>>>>>> ____ _ _ ____ 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- > de > >>>>>>> v > >>>>>>> > >>>>>>> > ________________________________________________________________ > >>>>>>> ____ _ _ ____ 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- > de > >>>>>>> v > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > ________________________________________________________________ > >>>>>>> ____ _ _ ____ OpenStack Development Mailing List (not for usage > >>>>>>> questions) > >>>>>>> Unsubscribe: > >>>>>>> OpenStack-dev- > requ...@lists.openstack.org?subject:unsubscribe<ht > >>>>>>> tp:/ / O > >>>>>>> penstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > >>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack- > de > >>>>>>> v > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> 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- > de > >>>>>>> v > >>>>>>> > >>>>>>> > ________________________________________________________________ > >>>>>>> ____ _ _ ____ 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- > de > >>>>>>> v > >>>>>> > >>>>>> > _________________________________________________________________ > >>>>>> _____ _ ___ 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 > > _______________________________________________________________________ > ___ > 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