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 <johnso...@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:dce3...@gmail.com] > *Sent:* Friday, March 10, 2017 1:58 AM > *To:* OpenStack Development Mailing List (not for usage questions) < > openstack-dev@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 <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 <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 > >
__________________________________________________________________________ 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