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 <as...@redhat.com> wrote:

> On Thu, Aug 25, 2016 at 7:35 AM, Gary Kotton <gkot...@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" <doug...@parksidesoftware.com>
> wrote:
> >
> >
> >     > On Mar 23, 2016, at 4:17 PM, Doug Wiegley <
> doug...@parksidesoftware.com> wrote:
> >     >
> >     > Migration script has been submitted, v1 is not going anywhere from
> stable/liberty or stable/mitaka, so it’s about to disappear from master.
> >     >
> >     > I’m thinking in this order:
> >     >
> >     > - remove jenkins jobs
> >     > - wait for heat to remove their jenkins jobs ([heat] added to this
> thread, so they see this coming before the job breaks)
> >     > - 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.eichber...@hpe.com> wrote:
> >     >>
> >     >> Yes, it’s Database only — though we changed the agent driver in
> the DB from V1 to V2 — so if you bring up a V2 with that database it should
> reschedule all your load balancers on the V2 agent driver.
> >     >>
> >     >> German
> >     >>
> >     >>
> >     >>
> >     >>
> >     >> On 3/8/16, 3:13 AM, "Samuel Bercovici" <samu...@radware.com>
> wrote:
> >     >>
> >     >>> So this looks like only a database migration, right?
> >     >>>
> >     >>> -----Original Message-----
> >     >>> From: Eichberger, German [mailto:german.eichber...@hpe.com]
> >     >>> Sent: Tuesday, March 08, 2016 12:28 AM
> >     >>> To: OpenStack Development Mailing List (not for usage questions)
> >     >>> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 -
> are weready?
> >     >>>
> >     >>> Ok, for what it’s worth we have contributed our migration
> script: https://review.openstack.org/#/c/289595/ — please look at this as
> a starting point and feel free to fix potential problems…
> >     >>>
> >     >>> Thanks,
> >     >>> German
> >     >>>
> >     >>>
> >     >>>
> >     >>>
> >     >>> On 3/7/16, 11:00 AM, "Samuel Bercovici" <samu...@radware.com>
> wrote:
> >     >>>
> >     >>>> As far as I recall, you can specify the VIP in creating the LB
> so you will end up with same IPs.
> >     >>>>
> >     >>>> -----Original Message-----
> >     >>>> From: Eichberger, German [mailto:german.eichber...@hpe.com]
> >     >>>> Sent: Monday, March 07, 2016 8:30 PM
> >     >>>> To: OpenStack Development Mailing List (not for usage questions)
> >     >>>> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1
> - are weready?
> >     >>>>
> >     >>>> Hi Sam,
> >     >>>>
> >     >>>> So if you have some 3rd party hardware you only need to change
> the
> >     >>>> database (your steps 1-5) since the 3rd party hardware will
> just keep
> >     >>>> load balancing…
> >     >>>>
> >     >>>> Now for Kevin’s case with the namespace driver:
> >     >>>> You would need a 6th step to reschedule the loadbalancers with
> the V2 namespace driver — which can be done.
> >     >>>>
> >     >>>> If we want to migrate to Octavia or (from one LB provider to
> another) it might be better to use the following steps:
> >     >>>>
> >     >>>> 1. Download LBaaS v1 information (Tenants, Flavors, VIPs,
> Pools, Health
> >     >>>> Monitors , Members) into some JSON format file(s) 2. Delete
> LBaaS v1 3.
> >     >>>> Uninstall LBaaS v1 4. Install LBaaS v2 5. Transform the JSON
> format
> >     >>>> file into some scripts which recreate the load balancers with
> your
> >     >>>> provider of choice —
> >     >>>>
> >     >>>> 6. Run those scripts
> >     >>>>
> >     >>>> The problem I see is that we will probably end up with
> different VIPs
> >     >>>> so the end user would need to change their IPs…
> >     >>>>
> >     >>>> Thanks,
> >     >>>> German
> >     >>>>
> >     >>>>
> >     >>>>
> >     >>>> On 3/6/16, 5:35 AM, "Samuel Bercovici" <samu...@radware.com>
> wrote:
> >     >>>>
> >     >>>>> As for a migration tool.
> >     >>>>> Due to model changes and deployment changes between LBaaS v1
> and LBaaS v2, I am in favor for the following process:
> >     >>>>>
> >     >>>>> 1. Download LBaaS v1 information (Tenants, Flavors, VIPs,
> Pools,
> >     >>>>> Health Monitors , Members) into some JSON format file(s) 2.
> Delete LBaaS v1 3.
> >     >>>>> Uninstall LBaaS v1 4. Install LBaaS v2 5. Import the data from
> 1 back
> >     >>>>> over LBaaS v2 (need to allow moving from falvor1-->flavor2,
> need to
> >     >>>>> make room to some custom modification for mapping between v1
> and v2
> >     >>>>> models)
> >     >>>>>
> >     >>>>> What do you think?
> >     >>>>>
> >     >>>>> -Sam.
> >     >>>>>
> >     >>>>>
> >     >>>>>
> >     >>>>>
> >     >>>>> -----Original Message-----
> >     >>>>> From: Fox, Kevin M [mailto:kevin....@pnnl.gov]
> >     >>>>> Sent: Friday, March 04, 2016 2:06 AM
> >     >>>>> To: OpenStack Development Mailing List (not for usage
> questions)
> >     >>>>> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1
> - are weready?
> >     >>>>>
> >     >>>>> Ok. Thanks for the info.
> >     >>>>>
> >     >>>>> Kevin
> >     >>>>> ________________________________________
> >     >>>>> From: Brandon Logan [brandon.lo...@rackspace.com]
> >     >>>>> Sent: Thursday, March 03, 2016 2:42 PM
> >     >>>>> To: openstack-dev@lists.openstack.org
> >     >>>>> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1
> - are weready?
> >     >>>>>
> >     >>>>> Just for clarity, V2 did not reuse tables, all the tables it
> uses are only for it.  The main problem is that v1 and v2 both have a pools
> resource, but v1 and v2's pool resource have different attributes.  With
> the way neutron wsgi works, if both v1 and v2 are enabled, it will combine
> both sets of attributes into the same validation schema.
> >     >>>>>
> >     >>>>> The other problem with v1 and v2 running together was only
> occurring when the v1 agent driver and v2 agent driver were both in use at
> the same time.  This may actually have been fixed with some agent updates
> in neutron, since that is common code.  It needs to be tested out though.
> >     >>>>>
> >     >>>>> Thanks,
> >     >>>>> Brandon
> >     >>>>>
> >     >>>>> On Thu, 2016-03-03 at 22:14 +0000, Fox, Kevin M wrote:
> >     >>>>>> Just because you had thought no one was using it outside of a
> PoC doesn't mean folks aren''t using it in production.
> >     >>>>>>
> >     >>>>>> We would be happy to migrate to Octavia. We were planning on
> doing just that by running both v1 with haproxy namespace, and v2 with
> Octavia and then pick off upgrading lb's one at a time, but the reuse of
> the v1 tables really was an unfortunate decision that blocked that activity.
> >     >>>>>>
> >     >>>>>> We're still trying to figure out a path forward.
> >     >>>>>>
> >     >>>>>> We have an outage window next month. after that, it could be
> about 6
> >     >>>>>> months before we could try a migration due to production load
> >     >>>>>> picking up for a while. I may just have to burn out all the
> lb's
> >     >>>>>> switch to v2, then rebuild them by hand in a marathon outage
> :/
> >     >>>>>>
> >     >>>>>> And then there's this thingy that also critically needs
> fixing:
> >     >>>>>> https://bugs.launchpad.net/neutron/+bug/1457556
> >     >>>>>>
> >     >>>>>> Thanks,
> >     >>>>>> Kevin
> >     >>>>>> ________________________________________
> >     >>>>>> From: Eichberger, German [german.eichber...@hpe.com]
> >     >>>>>> Sent: Thursday, March 03, 2016 12:47 PM
> >     >>>>>> To: OpenStack Development Mailing List (not for usage
> questions)
> >     >>>>>> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS
> v1 - are weready?
> >     >>>>>>
> >     >>>>>> Kevin,
> >     >>>>>>
> >     >>>>>> If we are offering a migration tool it would be namespace ->
> >     >>>>>> namespace (or maybe Octavia since [1]) - given the limitations
> >     >>>>>> nobody should be using the namespace driver outside a PoC so
> I am a
> >     >>>>>> bit confused why customers can't self migrate. With 3rd party
> Lbs I
> >     >>>>>> would assume vendors proving those scripts to make sure their
> >     >>>>>> particular hardware works with those. If you indeed need a
> migration
> >     >>>>>> from LBaaS
> >     >>>>>> V1 namespace -> LBaaS V2 namespace/Octavia please file an RfE
> with
> >     >>>>>> your use case so we can discuss it further...
> >     >>>>>>
> >     >>>>>> Thanks,
> >     >>>>>> German
> >     >>>>>>
> >     >>>>>> [1] https://review.openstack.org/#/c/286380
> >     >>>>>>
> >     >>>>>> From: "Fox, Kevin M" <kevin....@pnnl.gov<mailto:Kev
> in....@pnnl.gov>>
> >     >>>>>> Reply-To: "OpenStack Development Mailing List (not for usage
> >     >>>>>> questions)"
> >     >>>>>> <openstack-dev@lists.openstack.org<mailto:openstack
> -dev@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@lists.openstack.org<mailto:openstack
> -dev@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
> >     >>>>>> [sbaluk...@bluebox.net<mailto:sbaluk...@bluebox.net>]
> >     >>>>>> Sent: Wednesday, March 02, 2016 4:49 PM
> >     >>>>>> To: OpenStack Development Mailing List (not for usage
> questions)
> >     >>>>>> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS
> v1 - are weready?
> >     >>>>>>
> >     >>>>>> I am also on-board with removing LBaaS v1 as early as
> possible in the Newton cycle.
> >     >>>>>>
> >     >>>>>> On Wed, Mar 2, 2016 at 9:44 AM, Samuel Bercovici <
> samu...@radware.com<mailto:samu...@radware.com>> wrote:
> >     >>>>>> Thank you all for your response.
> >     >>>>>>
> >     >>>>>> In my opinion given that UI/HEAT will make Mitaka and will
> have one cycle to mature, it makes sense to remove LBaaS v1 in Newton.
> >     >>>>>> Do we want do discuss an upgrade process in the summit?
> >     >>>>>>
> >     >>>>>> -Sam.
> >     >>>>>>
> >     >>>>>>
> >     >>>>>> From: Bryan Jones
> >     >>>>>> [mailto:jone...@us.ibm.com<mailto:jone...@us.ibm.com>]
> >     >>>>>> Sent: Wednesday, March 02, 2016 5:54 PM
> >     >>>>>> To:
> >     >>>>>> openstack-dev@lists.openstack.org<mailto:openstack-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>
> >     >>>>>> E-mail: jone...@us.ibm.com<mailto:jone...@us.ibm.com>
> >     >>>>>>
> >     >>>>>>
> >     >>>>>> ----- Original message -----
> >     >>>>>> From: Justin Pomeroy
> >     >>>>>> <jpom...@linux.vnet.ibm.com<mailto:jpom...@linux.vnet.ibm.com
> >>
> >     >>>>>> To:
> >     >>>>>> openstack-dev@lists.openstack.org<mailto:openstack-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
> <samu...@radware.com<mailto:samu...@radware.com>> wrote:
> >     >>>>>>
> >     >>>>>> Hi,
> >     >>>>>>
> >     >>>>>> I have just notices the following change:
> https://review.openstack.org/#/c/286381 which aims to remove LBaaS v1.
> >     >>>>>> Is this planned for Mitaka or for Newton?
> >     >>>>>>
> >     >>>>>> While LBaaS v2 is becoming the default, I think that we
> should have the following before we replace LBaaS v1:
> >     >>>>>> 1.      Horizon Support - was not able to find any real
> activity on it
> >     >>>>>> 2.      HEAT Support - will it be ready in Mitaka?
> >     >>>>>>
> >     >>>>>> Do you have any other items that are needed before we get rid
> of LBaaS v1?
> >     >>>>>>
> >     >>>>>> -Sam.
> >     >>>>>>
> >     >>>>>>
> >     >>>>>>
> >     >>>>>>
> >     >>>>>>
> >     >>>>>>
> >     >>>>>>
> >     >>>>>> ____________________________________________________________
> ________
> >     >>>>>> _ _ ____ OpenStack Development Mailing List (not for usage
> >     >>>>>> questions)
> >     >>>>>> Unsubscribe:
> >     >>>>>> openstack-dev-requ...@lists.openstack.org<mailto:OpenStack
> -dev-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-requ...@lists.openstack.org?subject:unsubscribe
> <mailto:
> >     >>>>>> O penstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe>
> >     >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-dev
> >     >>>>>>
> >     >>>>>> ____________________________________________________________
> ________
> >     >>>>>> _ _ ____ OpenStack Development Mailing List (not for usage
> >     >>>>>> questions)
> >     >>>>>> Unsubscribe:
> >     >>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> <mailto:
> >     >>>>>> O penstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe>
> >     >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-dev
> >     >>>>>>
> >     >>>>>>
> >     >>>>>>
> >     >>>>>> ____________________________________________________________
> ________
> >     >>>>>> _ _ ____ OpenStack Development Mailing List (not for usage
> >     >>>>>> questions)
> >     >>>>>> Unsubscribe:
> >     >>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> <http:/
> >     >>>>>> / O penstack-dev-requ...@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= >
> >     >>>>>> sbaluk...@blueboxcloud.com<mailto:sbaluk...@blueboxcloud.com>
> >     >>>>>> 206-607-0660 x807
> >     >>>>>> ____________________________________________________________
> ________
> >     >>>>>> _ _ ____ OpenStack Development Mailing List (not for usage
> >     >>>>>> questions)
> >     >>>>>> Unsubscribe:
> >     >>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >     >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-dev
> >     >>>>>>
> >     >>>>>> ____________________________________________________________
> ________
> >     >>>>>> _ _ ____ OpenStack Development Mailing List (not for usage
> >     >>>>>> questions)
> >     >>>>>> Unsubscribe:
> >     >>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >     >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-dev
> >     >>>>>
> >     >>>>> ____________________________________________________________
> __________
> >     >>>>> _ ___ OpenStack Development Mailing List (not for usage
> questions)
> >     >>>>> Unsubscribe:
> >     >>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >     >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-dev
> >     >>>>>
> >     >>>>> ____________________________________________________________
> __________
> >     >>>>> _ ___ OpenStack Development Mailing List (not for usage
> questions)
> >     >>>>> Unsubscribe:
> >     >>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >     >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-dev
> >     >>>>>
> >     >>>>> ____________________________________________________________
> __________
> >     >>>>> _ ___ OpenStack Development Mailing List (not for usage
> questions)
> >     >>>>> Unsubscribe:
> >     >>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >     >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-dev
> >     >>>> ____________________________________________________________
> ___________
> >     >>>> ___ OpenStack Development Mailing List (not for usage questions)
> >     >>>> Unsubscribe:
> >     >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >     >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-dev
> >     >>>> ____________________________________________________________
> ___________
> >     >>>> ___ OpenStack Development Mailing List (not for usage questions)
> >     >>>> Unsubscribe:
> >     >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >     >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-dev
> >     >>> ____________________________________________________________
> ______________
> >     >>> OpenStack Development Mailing List (not for usage questions)
> >     >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >     >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-dev
> >     >>> ____________________________________________________________
> ______________
> >     >>> OpenStack Development Mailing List (not for usage questions)
> >     >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >     >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-dev
> >     >> ____________________________________________________________
> ______________
> >     >> OpenStack Development Mailing List (not for usage questions)
> >     >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >     >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >     >
> >
> >
> >     ____________________________________________________________
> ______________
> >     OpenStack Development Mailing List (not for usage questions)
> >     Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > ____________________________________________________________
> ______________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to