[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