> On Mar 24, 2016, at 7:48 AM, Hongbin Lu <hongbin...@huawei.com> wrote: > > > >> -----Original Message----- >> From: Assaf Muller [mailto:as...@redhat.com] >> Sent: March-24-16 9:24 AM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [Neutron][LBaaS][heat] Removing LBaaS v1 - >> are weready? >> >> On Thu, Mar 24, 2016 at 1:48 AM, Takashi Yamamoto >> <yamam...@midokura.com> wrote: >>> On Thu, Mar 24, 2016 at 6:17 AM, 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) >>> >>> magnum is relying on lbaasv1. (with heat) >> >> Is there anything blocking you from moving to v2? > > A ticket was created for that: > https://blueprints.launchpad.net/magnum/+spec/migrate-to-lbaas-v2 . It will > be picked up by contributors once it is approved. Please give us sometimes to > finish the work.
Approved. >>>> - remove q-lbaas from devstack, and any references to lbaas v1 in >> devstack-gate or infra defaults. >>>> - remove v1 code from neutron-lbaas >>>> >>>> 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:kevin....@pnnl.gov>> >>>>>>>>> Reply-To: "OpenStack Development Mailing List (not for usage >>>>>>>>> questions)" >>>>>>>>> <openstack-dev@lists.openstack.org<mailto:openstack- >> d...@lists.op >>>>>>>>> enst >>>>>>>>> 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- >> d...@lists.op >>>>>>>>> enst >>>>>>>>> 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- >> d...@lists.ope >>>>>>>>> nsta >>>>>>>>> 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- >> d...@lists.ope >>>>>>>>> nsta >>>>>>>>> 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- >> r >>>>>>>>> eque s t @lists.openstack.org>?subject:unsubscribe >>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack- >> de >>>>>>>>> v >>>>>>>>> >>>>>>>>> >> ________________________________________________________________ >>>>>>>>> ____ _ _ ____ 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- >> de >>>>>>>>> v >>>>>>>>> >>>>>>>>> >> ________________________________________________________________ >>>>>>>>> ____ _ _ ____ 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- >> de >>>>>>>>> v >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> ________________________________________________________________ >>>>>>>>> ____ _ _ ____ OpenStack Development Mailing List (not for usage >>>>>>>>> questions) >>>>>>>>> Unsubscribe: >>>>>>>>> OpenStack-dev- >> requ...@lists.openstack.org?subject:unsubscribe<ht >>>>>>>>> tp:/ / O >>>>>>>>> penstack-dev-requ...@lists.openstack.org?subject:unsubscribe> >>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack- >> de >>>>>>>>> v >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Stephen Balukoff >>>>>>>>> Principal Technologist >>>>>>>>> Blue Box, An IBM Company >>>>>>>>> www.blueboxcloud.com<http://www.blueboxcloud.com> >>>>>>>>> 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- >> de >>>>>>>>> v >>>>>>>>> >>>>>>>>> >> ________________________________________________________________ >>>>>>>>> ____ _ _ ____ 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- >> de >>>>>>>>> v >>>>>>>> >>>>>>>> >> _________________________________________________________________ >>>>>>>> _____ _ ___ 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
