[openstack-dev] [Neutron][LBaaS][heat] Removing LBaaS v1 - are weready?
Michael Johnson
johnsomor at gmail.com
Fri Mar 10 17:27:01 UTC 2017
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 <mailto:assaf at redhat.com> > wrote:
On Thu, Aug 25, 2016 at 7:35 AM, Gary Kotton <gkotton at vmware.com <mailto: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 <mailto:dougwig at parksidesoftware.com> > wrote:
>
>
> > On Mar 23, 2016, at 4:17 PM, Doug Wiegley <dougwig at parksidesoftware.com <mailto: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 <mailto: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 <mailto: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 <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 <mailto: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 <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 <mailto: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 <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 <mailto:brandon.logan at RACKSPACE.COM> ]
> >>>>> Sent: Thursday, March 03, 2016 2:42 PM
> >>>>> To: openstack-dev at lists.openstack.org <mailto: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 <mailto: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> <mailto: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.openstack.org> <mailto:openstack-dev at lists.openst <mailto:openstack-dev at lists.openst>
> >>>>>> a
> >>>>>> c
> >>>>>> k.org <http://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.openstack.org> <mailto:openstack-dev at lists.openst <mailto:openstack-dev at lists.openst>
> >>>>>> a
> >>>>>> c
> >>>>>> k.org <http://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> <mailto: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> <mailto: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> <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.openstack.org> <mailto:openstack-dev at lists.opensta <mailto:openstack-dev at 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: jonesbr at us.ibm.com <mailto:jonesbr at us.ibm.com> <mailto: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> <mailto: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.openstack.org> <mailto:openstack-dev at lists.opensta <mailto:openstack-dev at 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 <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-request at lists.openstack.org> <mailto:OpenStack-dev-reque <mailto:OpenStack-dev-reque>
> >>>>>> s t @lists.openstack.org <http://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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe> <mailto:
> >>>>>> O penStack-dev-request at lists.openstack.org?subject:unsubscribe <http://penStack-dev-request@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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe> <mailto:
> >>>>>> O penStack-dev-request at lists.openstack.org?subject:unsubscribe <http://penStack-dev-request@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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe> <http:/
> >>>>>> / O penStack-dev-request at lists.openstack.org?subject:unsubscribe <http://penStack-dev-request@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> <https://urldefense.proofpoint.com/v2/url?u=http-3A__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=> &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> <mailto: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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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/20170310/2915a64c/attachment.html>
More information about the OpenStack-dev
mailing list