Open Stack

> -----Original Message-----
> From: Assaf Muller [mailto:assaf at 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
> <yamamoto at midokura.com> wrote:
> > On Thu, Mar 24, 2016 at 6:17 AM, Doug Wiegley
> > <dougwig at 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.eichberger at 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" <SamuelB at Radware.com> wrote:
> >>>
> >>>> So this looks like only a database migration, right?
> >>>>
> >>>> -----Original Message-----
> >>>> From: Eichberger, German [mailto:german.eichberger at 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" <SamuelB at 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.eichberger at 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" <SamuelB at 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.Fox at 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.logan at RACKSPACE.COM]
> >>>>>> Sent: Thursday, March 03, 2016 2:42 PM
> >>>>>> To: openstack-dev at 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.eichberger at 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.Fox at pnnl.gov<mailto:Kevin.Fox at pnnl.gov>>
> >>>>>>> Reply-To: "OpenStack Development Mailing List (not for usage
> >>>>>>> questions)"
> >>>>>>> <openstack-dev at lists.openstack.org<mailto:openstack-
> dev at 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 at lists.openstack.org<mailto:openstack-
> dev at 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
> >>>>>>> [sbalukoff at bluebox.net<mailto:sbalukoff at 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
> <SamuelB at radware.com<mailto:SamuelB at 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:jonesbr at us.ibm.com<mailto:jonesbr at us.ibm.com>]
> >>>>>>> Sent: Wednesday, March 02, 2016 5:54 PM
> >>>>>>> To:
> >>>>>>> openstack-dev at lists.openstack.org<mailto:openstack-
> dev at 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: jonesbr at us.ibm.com<mailto:jonesbr at us.ibm.com>
> >>>>>>>
> >>>>>>>
> >>>>>>> ----- Original message -----
> >>>>>>> From: Justin Pomeroy
> >>>>>>> <jpomero at linux.vnet.ibm.com<mailto:jpomero at linux.vnet.ibm.com>>
> >>>>>>> To:
> >>>>>>> openstack-dev at lists.openstack.org<mailto:openstack-
> dev at 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
> <SamuelB at Radware.com<mailto:SamuelB at 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-request at 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-
> request at lists.openstack.org?subject:unsubscribe<mailto:
> >>>>>>> O penStack-dev-request at 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-
> request at lists.openstack.org?subject:unsubscribe<mailto:
> >>>>>>> O penStack-dev-request at 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-
> request at lists.openstack.org?subject:unsubscribe<ht
> >>>>>>> tp:/ / O
> >>>>>>> penStack-dev-request at 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>
> >>>>>>> sbalukoff at blueboxcloud.com<mailto:sbalukoff at blueboxcloud.com>
> >>>>>>> 206-607-0660 x807
> >>>>>>>
> ________________________________________________________________
> >>>>>>> ____ _ _ ____ 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-
> de
> >>>>>>> v
> >>>>>>>
> >>>>>>>
> ________________________________________________________________
> >>>>>>> ____ _ _ ____ 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-
> de
> >>>>>>> v
> >>>>>>
> >>>>>>
> _________________________________________________________________
> >>>>>> _____ _ ___ 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
> >>>>
> ___________________________________________________________________
> >>>> _______ 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