[openstack-dev] [Neutron][LBaaS][heat] Removing LBaaS v1 - are weready?
Syed Armani
dce3062 at gmail.com
Wed Mar 15 11:05:12 UTC 2017
Hello Michael,
Thank you for the assurances regarding neutron-lbaas to octavia migration.
Sometimes, i honestly feel that OpenStack needs somebody who can implement
*a* rule something like "WE DO NOT BREAK USERSPACE!" rule from linux
kernel community.
Cheers,
Syed
On Fri, Mar 10, 2017 at 10:57 PM, Michael Johnson <johnsomor at gmail.com>
wrote:
> Hi Syed,
>
>
>
> To my knowledge the LBaaS team did not create any upgrade plan or tools to
> move load balancers from V1 to V2. The data model is significantly
> different (and better) with V2 and I suspect that caused some challenges.
>
> I know there was a, as-is, database conversion script contributed by an
> operator/packager that might help someone develop a migration path if their
> deployment wasn’t using one of the incompatible configurations, but that
> would only be one piece to the puzzle.
>
>
>
> Since development beyond security fixes for v1 halted over two releases
> ago and the last of the v1 code will be removed from OpenStack in about 32
> days (mitaka goes EOL 4/10/17) I think it is going to be left to the last
> few folks still running LBaaS v1 to plan their migrations. Most of the
> LBaaS team from the time of v1 deprecation are no longer on the team so we
> don’t really have folks experienced with v1 available any longer.
>
>
>
> I cannot speak to how hard or easy it would be to create a heat migration
> template to recreate the v1 load balancers under v2.
>
>
>
> Beyond that, I can assure you that the migration from neutron-lbaas to
> octavia will have migration procedures and tools to automate the process.
>
>
>
> Michael
>
>
>
> *From:* Syed Armani [mailto:dce3062 at gmail.com]
> *Sent:* Friday, March 10, 2017 1:58 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev at lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Neutron][LBaaS][heat] Removing LBaaS v1 -
> are weready?
>
>
>
> Folks,
>
>
>
> I am going to ask the question raised by Zane one more time:
>
>
>
> Is there a migration plan for Heat users who have existing stacks
> containing the v1 resources?
>
>
>
> Cheers,
>
> Syed
>
>
>
> On Thu, Aug 25, 2016 at 7:10 PM, Assaf Muller <assaf at redhat.com> wrote:
>
> On Thu, Aug 25, 2016 at 7:35 AM, Gary Kotton <gkotton at vmware.com> wrote:
> > Hi,
> > At the moment it is still not clear to me the upgrade process from V1 to
> V2. The migration script https://review.openstack.org/#/c/289595/ has yet
> to be approved. Does this support all drivers or is this just the default
> reference implementation driver?
>
> The migration script doesn't have a test, so we really have no idea if
> it's going to work.
>
>
> > Are there people still using V1?
> > Thanks
> > Gary
> >
> > On 8/25/16, 4:25 AM, "Doug Wiegley" <dougwig at parksidesoftware.com>
> wrote:
> >
> >
> > > On Mar 23, 2016, at 4:17 PM, 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)
> > > - remove q-lbaas from devstack, and any references to lbaas v1 in
> devstack-gate or infra defaults.
> > > - remove v1 code from neutron-lbaas
> >
> > FYI, all of the above have completed, and the final removal is in
> the merge queue: https://review.openstack.org/#/c/286381/
> >
> > Mitaka will be the last stable branch with lbaas v1.
> >
> > Thanks,
> > doug
> >
> > >
> > > 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:Kev
> in.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.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 at lists.openstack.org<mailto:openstack
> -dev at 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
> > >>>>>> [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@
> 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 <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@
> 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
> <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-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-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-dev
> > >>>>>>
> > >>>>>> ____________________________________________________________
> ________
> > >>>>>> _ _ ____ 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-dev
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> ____________________________________________________________
> ________
> > >>>>>> _ _ ____ OpenStack Development Mailing List (not for usage
> > >>>>>> questions)
> > >>>>>> Unsubscribe:
> > >>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> <http:/
> > >>>>>> / O penStack-dev-request at 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<https://urldefense.proofpoint.com/v2/
> url?u=http-3A__www.blueboxcloud.com&d=CwIGaQ&c=
> Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=
> VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=vJLP-
> 7XciuDVakdowfZ0u_NPJGht_-SRMTpAZlP_9bg&s=J7W2p5eCYWf19MBaPHm_M8vmzWoiQ-
> xvl2KyjA5n8zw&e= >
> > >>>>>> 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-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
> >
> >
> > ____________________________________________________________
> ______________
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170315/ded1cbce/attachment.html>
More information about the OpenStack-dev
mailing list