Salvatore Thanks for your clarification below around the blueprint.
> For LBaaS v2 therefore the relationship between it and Octavia should be the same as with any other > backend. I see Octavia has a blueprint for a "network driver" - and the derivable of that should definitely be > part of the LBaaS project. > For the rest, it would seem a bit strange to me if the LBaaS project incorporated a backend as well. After > all, LBaaS v1 did not incorporate haproxy! > Also, as Adam points out, Nova does not incorporate an Hypervisor. In my vision Octavia is a LBaaS framework that should not be tied to ha-proxy. The interfaces should be clean and at a high enough level that we can switch load-balancer. We should be able to switch the load-balancer to nginx so to me the analogy is more Octavia+LBaaSV2 == nova and hypervisor == load-balancer. I am not sure the group is in agreement on the definition I just wrote. Also going back the definition of Octavia being a backend then I agree that we should write a blueprint to incorporate Octavia as a network driver. I guess I had always envisioned what we now call Octavia to be part of the LBaaS service itself and have ha-proxy, nginx be the drivers and not have the driver level be at the Octavia cut-over point, Given this new "design" I am now wondering why we didn't just write a driver for Libra and improved on Libra since to me that is the now the driver level we are discussing. Regards Susanne On Tue, Sep 2, 2014 at 9:18 AM, Salvatore Orlando <sorla...@nicira.com> wrote: > Some more comments from me inline. > Salvatore > > > On 2 September 2014 11:06, Adam Harwell <adam.harw...@rackspace.com> > wrote: > >> I also agree with most of what Brandon said, though I am slightly >> concerned by the talk of merging Octavia and [Neutron-]LBaaS-v2 codebases. >> > > Beyond all the reasons listed in this thread - merging codebases is always > more difficult that what it seems! > Also it seems to me there's not yet a clear path for LBaaS v2. Mostly > because of the ongoing neutron incubator discussion. > However in my opinion there are 3 paths (and I have no idea whether they > might be applicable to Octavia as a standalone project). > 1) Aim at becoming part of neutron via the incubator or any equivalent > mechanisms > 2) Evolve in loosely coupled fashion with neutron, but still be part of > the networking program. (This means that LBaaS APIs will be part of > Openstack Network APIs) > 3) Evolve independently from neutron, and become part of a new program. I > have no idea however whether there's enough material to have a "load > balancing" program, and what would be the timeline for that. > > >> [blogan] "I think the best course of action is to get Octavia itself into >> the same codebase as LBaaS (Neutron or spun out)." >> [sballe] "What I am trying to now understand is how we will move Octavia >> into the new LBaaS project?" >> >> >> I didn't think that was ever going to be the plan -- sure, we'd have an >> Octavia driver that is part of the [Neutron-]LBaaS-v2 codebase (which >> Susanne did mention as well), but nothing more than that. The actual >> Octavia code would still be in its own project at the end of all of this, >> right? The driver code could be added to [Neutron-]LbaaS-v2 at any point >> once Octavia is mature enough to be used, just by submitting it as a CR, I >> believe. Doug might be able to comment on that, since he maintains the A10 >> driver? >> > > From what I gathered so far Octavia is a fully fledged load balancing > virtual appliance which (at least in its first iterations) will leverage > haproxy. > As also stated earlier in this thread it's a peer of commercial appliances > from various vendors. > > For LBaaS v2 therefore the relationship between it and Octavia should be > the same as with any other backend. I see Octavia has a blueprint for a > "network driver" - and the derivable of that should definitely be part of > the LBaaS project. > For the rest, it would seem a bit strange to me if the LBaaS project > incorporated a backend as well. After all, LBaaS v1 did not incorporate > haproxy! > Also, as Adam points out, Nova does not incorporate an Hypervisor. > > >> >> Also, I know I'm opening this same can of worms again, but I am curious >> about the HP mandate that "everything must be OpenStack" when it comes to >> Octavia. Since HP's offering would be "[Neutron-]LBaaS-v2", which happens >> to use Octavia as a backend, does it matter whether Octavia is an official >> OpenStack project**? If HP can offer Cloud Compute through Nova, and Nova >> uses some hypervisor like Xen or KVM (neither of which are a part of >> OpenStack), I am not sure how it is different to offer Cloud Load >> Balancing via [Neutron-]LBaaS-v2 which could be using a non-Openstack >> implementation for the backend. I don't see "Octavia needs to be in >> Openstack" as a blocker so long as the "LBaaS API" is part of OpenStack. >> >> **NOTE: I AM DEFINITELY STILL IN FAVOR OF OCTAVIA BEING AN OPENSTACK >> PROJECT. THIS IS JUST AN EXAMPLE FOR THE SAKE OF THIS PARTICULAR ARGUMENT. >> PLEASE DON'T THINK THAT I'M AGAINST OCTAVIA BEING OFFICIALLY INCUBATED!** >> > >> >> --Adam >> >> >> https://keybase.io/rm_you >> >> >> >> On 9/1/14 10:12 PM, "Brandon Logan" <brandon.lo...@rackspace.com> wrote: >> >> >Hi Susanne and everyone, >> > >> >My opinions are that keeping it in stackforge until it gets mature is >> >the best solution. I'm pretty sure we can all agree on that. Whenever >> >it is mature then, and only then, we should try to get it into openstack >> >one way or another. If Neutron LBaaS v2 is still incubated then it >> >should be relatively easy to get it in that codebase. If Neutron LBaaS >> >has already spun out, even easier for us. If we want Octavia to just >> >become an openstack project all its own then that will be the difficult >> >part. >> > >> >I think the best course of action is to get Octavia itself into the same >> >codebase as LBaaS (Neutron or spun out). They do go together, and the >> >maintainers will almost always be the same for both. This makes even >> >more sense when LBaaS is spun out into its own project. >> > >> >I really think all of the answers to these questions will fall into >> >place when we actually deliver a product that we are all wanting and >> >talking about delivering with Octavia. Once we prove that we can all >> >come together as a community and manage a product from inception to >> >maturity, we will then have the respect and trust to do what is best for >> >an Openstack LBaaS product. >> > >> >Thanks, >> >Brandon >> > >> >On Mon, 2014-09-01 at 10:18 -0400, Susanne Balle wrote: >> >> Kyle, Adam, >> >> >> >> >> >> >> >> Based on this thread Kyle is suggesting the follow moving forward >> >> plan: >> >> >> >> >> >> >> >> 1) We incubate Neutron LBaaS V2 in the ³Neutron² incubator ³and freeze >> >> LBaas V1.0² >> >> 2) ³Eventually² It graduates into a project under the networking >> >> program. >> >> 3) ³At that point² We deprecate Neutron LBaaS v1. >> >> >> >> >> >> >> >> The words in ³xx³ are works I added to make sure I/We understand the >> >> whole picture. >> >> >> >> >> >> >> >> And as Adam mentions: Octavia != LBaaS-v2. Octavia is a peer to F5 / >> >> Radware / A10 / etc appliances which is a definition I agree with BTW. >> >> >> >> >> >> >> >> What I am trying to now understand is how we will move Octavia into >> >> the new LBaaS project? >> >> >> >> >> >> >> >> If we do it later rather than develop Octavia in tree under the new >> >> incubated LBaaS project when do we plan to bring it in-tree from >> >> Stackforge? Kilo? Later? When LBaaS is a separate project under the >> >> Networking program? >> > >> >> >> >> >> >> What are the criteria to bring a driver into the LBaaS project and >> >> what do we need to do to replace the existing reference driver? Maybe >> >> adding a software driver to LBaaS source tree is less of a problem >> >> than converting a whole project to an OpenStack project. >> > >> >> >> >> >> >> Again I am open to both directions I just want to make sure we >> >> understand why we are choosing to do one or the other and that our >> >> decision is based on data and not emotions. >> >> >> >> >> >> >> >> I am assuming that keeping Octavia in Stackforge will increase the >> >> velocity of the project and allow us more freedom which is goodness. >> >> We just need to have a plan to make it part of the Openstack LBaaS >> >> project. >> >> >> >> >> >> >> >> Regards Susanne >> >> >> >> >> >> >> >> >> >> On Sat, Aug 30, 2014 at 2:09 PM, Adam Harwell >> >> <adam.harw...@rackspace.com> wrote: >> >> Only really have comments on two of your related points: >> >> >> >> >> >> [Susanne] To me Octavia is a driver so it is very hard to me >> >> to think of it as a standalone project. It needs the new >> >> Neutron LBaaS v2 to function which is why I think of them >> >> together. This of course can change since we can add whatever >> >> layers we want to Octavia. >> >> >> >> >> >> [Adam] I guess I've always shared Stephen's >> >> viewpoint ‹ Octavia != LBaaS-v2. Octavia is a peer to F5 / >> >> Radware / A10 / etcappliances, not to an Openstack API layer >> >> like Neutron-LBaaS. It's a little tricky to clearly define >> >> this difference in conversation, and I have noticed that quite >> >> a few people are having the same issue differentiating. In a >> >> small group, having quite a few people not on the same page is >> >> a bit scary, so maybe we need to really sit down and map this >> >> out so everyone is together one way or the other. >> >> >> >> >> >> [Susanne] Ok now I am confusedŠ But I agree with you that it >> >> need to focus on our use cases. I remember us discussing >> >> Octavia being the refenece implementation for OpenStack LBaaS >> >> (whatever that is). Has that changed while I was on vacation? >> >> >> >> >> >> [Adam] I believe that having the Octavia "driver" (not the >> >> Octavia codebase itself, technically) become the reference >> >> implementation for Neutron-LBaaS is still the plan in my eyes. >> >> The Octavia Driver in Neutron-LBaaS is a separate bit of code >> >> from the actual Octavia project, similar to the way the A10 >> >> driver is a separate bit of code from the A10 appliance. To do >> >> that though, we need Octavia to be fairly close to fully >> >> functional. I believe we can do this because even though the >> >> reference driver would then require an additional service to >> >> run, what it requires is still fully-open-source and (by way >> >> of our plan) available as part of OpenStack core. >> >> >> >> >> >> --Adam >> >> >> >> >> >> https://keybase.io/rm_you >> >> >> >> >> >> >> >> >> >> From: Susanne Balle <sleipnir...@gmail.com> >> >> Reply-To: "OpenStack Development Mailing List (not for usage >> >> questions)" <openstack-dev@lists.openstack.org> >> >> Date: Friday, August 29, 2014 9:19 AM >> >> To: "OpenStack Development Mailing List (not for usage >> >> questions)" <openstack-dev@lists.openstack.org> >> >> >> >> Subject: Re: [openstack-dev] [neutron][lbaas][octavia] >> >> >> >> >> >> >> >> Stephen >> >> >> >> >> >> >> >> See inline comments. >> >> >> >> >> >> >> >> Susanne >> >> >> >> >> >> >> >> ----------------------------------------- >> >> >> >> >> >> >> >> Susanne-- >> >> >> >> >> >> >> >> I think you are conflating the difference between >> >> "OpenStack incubation" and "Neutron incubator." These >> >> are two very different matters and should be treated >> >> separately. So, addressing each one individually: >> >> >> >> >> >> >> >> "OpenStack Incubation" >> >> >> >> I think this has been the end-goal of Octavia all >> >> along and continues to be the end-goal. Under this >> >> scenario, Octavia is its own stand-alone project with >> >> its own PTL and core developer team, its own >> >> governance, and should eventually become part of the >> >> integrated OpenStack release. No project ever starts >> >> out as "OpenStack incubated." >> >> >> >> >> >> >> >> [Susanne] I totally agree that the end goal is for >> >> Neutron LBaaS to become its own incubated project. I >> >> did miss the nuance that was pointed out by Mestery in >> >> an earlier email that if a Neutron incubator project >> >> wants to become a separate project it will have to >> >> apply for incubation again or at that time. It was my >> >> understanding that such a Neutron incubated project >> >> would be grandfathered in but again we do not have >> >> much details on the process yet. >> >> >> >> >> >> >> >> To me Octavia is a driver so it is very hard to me to >> >> think of it as a standalone project. It needs the new >> >> Neutron LBaaS v2 to function which is why I think of >> >> them together. This of course can change since we can >> >> add whatever layers we want to Octavia. >> >> >> >> >> >> >> >> "Neutron Incubator" >> >> >> >> This has only become a serious discussion in the last >> >> few weeks and has yet to land, so there are many >> >> assumptions about this which don't pan out (either >> >> because of purposeful design and governance decisions, >> >> or because of how this project actually ends up being >> >> implemented from a practical standpoint). But given >> >> the inherent limitations about making statements with >> >> so many unknowns, the following seem fairly clear from >> >> what has been shared so far: >> >> >> >> · Neutron incubator is the on-ramp for projects which >> >> should eventually become a part of Neutron itself. >> >> >> >> · Projects which enter the Neutron incubator on-ramp >> >> should be fairly close to maturity in their final >> >> form. I think the intent here is for them to live in >> >> incubator for 1 or 2 cycles before either being merged >> >> into Neutron core, or being ejected (as abandoned, or >> >> as a separate project). >> >> >> >> · Neutron incubator projects effectively do not have >> >> their own PTL and core developer team, and do not have >> >> their own governance. >> >> >> >> [Susanne] Ok I missed the last point. In an earlier >> >> discussion Mestery implied that an incubated project >> >> would have at least one or two of its own cores. Maybe >> >> that changed between now and then. >> >> >> >> In addition we know the following about Neutron LBaaS >> >> and Octavia: >> >> >> >> · It's already (informally?) agreed that the ultimate >> >> long-term place for a LBaaS solution is probably to be >> >> spun out into its own project, which might >> >> appropriately live under a yet-to-be-defined master >> >> "Networking" project. (This would make Neutron, LBaaS, >> >> VPNaaS, FWaaS, etc. effective "peer" projects under >> >> the Networking umbrella.) Since this "Networking" >> >> umbrella project has even less defined about it than >> >> Neutron incubator, it's impossible to know whether >> >> being a part of Neutron incubator would be of any >> >> benefit to Octavia (or, conversely, to Neutron >> >> incubator) at all as an on-ramp to becoming part of >> >> "Networking." Presumably, Octavia might fit well under >> >> the "Networking" umbrella-- but, again, with nothing >> >> defined there it's impossible to draw any reasonable >> >> conclusions at this time. >> >> >> >> [Susanne] We are in agreement here. This was the >> >> reasons we had the ad-hoc meeting in Atlanta so get a >> >> feel for hw people felt if we made Neutron LBaaS its >> >> own project and also how we got an operator large >> >> scale LBaaS that fit most of our service provider >> >> requirements. I am just worried because you keep on >> >> talking of Octavia as a standaloe project. To me it is >> >> an extension of Neutron LBaaS or of a new LBaaS Š. I >> >> do not see us (== me) use Octavia in a non OpenStack >> >> context. And yes it is a driver that I am hoping we >> >> all expect to become the reference implementation for >> >> LBaaS. >> >> >> >> · When the LBaaS component spins out of Neutron, it >> >> will more than likely not be Octavia. Octavia >> >> is intentionally less friendly to 3rd party load >> >> balancer vendors both because it's envisioned that >> >> Octavia would just be another implementation which >> >> lives along-side said 3rd party vendor products >> >> (plugging into a higher level LBaaS layer via a >> >> driver), and because we don't want to have to >> >> compromise certain design features of Octavia to meet >> >> the lowest common denominator 3rd party vendor >> >> product. (3rd party vendors are welcome, but we will >> >> not make design compromises to meet the needs of a >> >> proprietary product-- compatibility with available >> >> open-source products and standards trumps this.) >> >> >> >> [Susanne] Ok now I am confusedŠ But I agree with you >> >> that it need to focus on our use cases. I remember us >> >> discussing Octavia being the refenece implementation >> >> for OpenStack LBaaS (whatever that is). Has that >> >> changed while I was on vacation? >> >> >> >> The end-game for the above point is: In the future I >> >> see "Openstack LBaaS" (or whatever the project calls >> >> itself) being a separate but complimentary project to >> >> Octavia. >> >> >> >> · While its true that we would like Octavia to become >> >> the reference implementation for Neutron LBaaS, we are >> >> nowhere near being able to deliver on that. Attempting >> >> to become a part of Neutron LBaaS right now is likely >> >> just to create frustration (and very little merged >> >> code) for both the Octavia and Neutron teams. >> >> >> >> [Susanne] Agreed. >> >> >> >> So given that the only code in Octavia right now are a >> >> few database migrations, we are very, very far away >> >> from being ready for either OpenStack incubation or >> >> the Neutron incubator project. I don't think it's very >> >> useful to be spending time right now worrying about >> >> either of these outcomes: We should be working on >> >> Octavia! >> >> >> >> [Susanne] Agreed. You suggested we discuss this on the >> >> ML NOW. I wanted to wait until the summit given that >> >> we would have more info on Neutron incubation, etc. I >> >> haven¹t seen much written down on the Neutron >> >> incubator project so most of what we are doing is >> >> guessingŠ. >> >> >> >> Please also understand: I realize that probably the >> >> reason you're asking this right now is because you >> >> have a mandate within your organization to use only >> >> "official" OpenStack branded components, and if >> >> Octavia doesn't fall within that category, you won't >> >> be able to use it. Of course everyone working on this >> >> project wants to make that happen too, so we're doing >> >> everything we can to make sure we don't jeopardize >> >> that possibility. And there are enough voices in this >> >> project that want that to happen, so I think if we >> >> strayed from the path to get there, there would be >> >> sufficient clangor over this that it would be hard to >> >> miss. But I don't think there's anyone at all at this >> >> time that can honestly give you a promise that Octavia >> >> definitely will be incubated and will definitely end >> >> up in the integrated OpenStack release. >> >> >> >> >> >> >> >> If you want to increase the chances of that happening, >> >> please help push the project forward! >> >> >> >> >> >> >> >> [Susanne] That is what HP is doing. Remember we were >> >> here from the beginning helping change the direction >> >> for LBaaS. >> >> >> >> >> >> >> >> Thanks, >> >> >> >> Stephen >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Aug 28, 2014 at 9:52 PM, Stephen Balukoff >> >> <sbaluk...@bluebox.net> wrote: >> >> Susanne-- >> >> >> >> >> >> I think you are conflating the difference >> >> between "OpenStack incubation" and "Neutron >> >> incubator." These are two very different >> >> matters and should be treated separately. So, >> >> addressing each one individually: >> >> >> >> >> >> "OpenStack Incubation" >> >> I think this has been the end-goal of Octavia >> >> all along and continues to be the end-goal. >> >> Under this scenario, Octavia is its own >> >> stand-alone project with its own PTL and core >> >> developer team, its own governance, and should >> >> eventually become part of the integrated >> >> OpenStack release. No project ever starts out >> >> as "OpenStack incubated." >> >> >> >> >> >> "Neutron Incubator" >> >> This has only become a serious discussion in >> >> the last few weeks and has yet to land, so >> >> there are many assumptions about this which >> >> don't pan out (either because of purposeful >> >> design and governance decisions, or because of >> >> how this project actually ends up being >> >> implemented from a practical standpoint). But >> >> given the inherent limitations about making >> >> statements with so many unknowns, the >> >> following seem fairly clear from what has been >> >> shared so far: >> >> * Neutron incubator is the on-ramp for >> >> projects which should eventually >> >> become a part of Neutron itself. >> >> * Projects which enter the Neutron >> >> incubator on-ramp should be fairly >> >> close to maturity in their final form. >> >> I think the intent here is for them to >> >> live in incubator for 1 or 2 cycles >> >> before either being merged into >> >> Neutron core, or being ejected (as >> >> abandoned, or as a separate project). >> >> * Neutron incubator projects effectively >> >> do not have their own PTL and core >> >> developer team, and do not have their >> >> own governance. >> >> In addition we know the following about >> >> Neutron LBaaS and Octavia: >> >> * It's already (informally?) agreed that >> >> the ultimate long-term place for a >> >> LBaaS solution is probably to be spun >> >> out into its own project, which might >> >> appropriately live under a >> >> yet-to-be-defined master "Networking" >> >> project. (This would make Neutron, >> >> LBaaS, VPNaaS, FWaaS, etc. effective >> >> "peer" projects under the Networking >> >> umbrella.) Since this "Networking" >> >> umbrella project has even less defined >> >> about it than Neutron incubator, it's >> >> impossible to know whether being a >> >> part of Neutron incubator would be of >> >> any benefit to Octavia (or, >> >> conversely, to Neutron incubator) at >> >> all as an on-ramp to becoming part of >> >> "Networking." Presumably, Octavia >> >> might fit well under the "Networking" >> >> umbrella-- but, again, with nothing >> >> defined there it's impossible to draw >> >> any reasonable conclusions at this >> >> time. >> >> * When the LBaaS component spins out of >> >> Neutron, it will more than likely not >> >> be Octavia. Octavia is intentionally >> >> less friendly to 3rd party load >> >> balancer vendors both because it's >> >> envisioned that Octavia would just be >> >> another implementation which lives >> >> along-side said 3rd party vendor >> >> products (plugging into a higher level >> >> LBaaS layer via a driver), and because >> >> we don't want to have to compromise >> >> certain design features of Octavia to >> >> meet the lowest common denominator 3rd >> >> party vendor product. (3rd party >> >> vendors are welcome, but we will not >> >> make design compromises to meet the >> >> needs of a proprietary product-- >> >> compatibility with available >> >> open-source products and standards >> >> trumps this.) >> >> * The end-game for the above point is: >> >> In the future I see "Openstack >> >> LBaaS" (or whatever the project calls >> >> itself) being a separate but >> >> complimentary project to Octavia. >> >> * While its true that we would like >> >> Octavia to become the reference >> >> implementation for Neutron LBaaS, we >> >> are nowhere near being able to deliver >> >> on that. Attempting to become a part >> >> of Neutron LBaaS right now is likely >> >> just to create frustration (and very >> >> little merged code) for both the >> >> Octavia and Neutron teams. >> >> >> >> >> >> >> >> >> >> So given that the only code in Octavia right >> >> now are a few database migrations, we are >> >> very, very far away from being ready for >> >> either OpenStack incubation or the Neutron >> >> incubator project. I don't think it's very >> >> useful to be spending time right now worrying >> >> about either of these outcomes: We should be >> >> working on Octavia! >> >> >> >> >> >> Please also understand: I realize that >> >> probably the reason you're asking this right >> >> now is because you have a mandate within your >> >> organization to use only "official" OpenStack >> >> branded components, and if Octavia doesn't >> >> fall within that category, you won't be able >> >> to use it. Of course everyone working on this >> >> project wants to make that happen too, so >> >> we're doing everything we can to make sure we >> >> don't jeopardize that possibility. And there >> >> are enough voices in this project that want >> >> that to happen, so I think if we strayed from >> >> the path to get there, there would be >> >> sufficient clangor over this that it would be >> >> hard to miss. But I don't think there's anyone >> >> at all at this time that can honestly give you >> >> a promise that Octavia definitely will be >> >> incubated and will definitely end up in the >> >> integrated OpenStack release. >> >> >> >> >> >> If you want to increase the chances of that >> >> happening, please help push the project >> >> forward! >> >> >> >> >> >> Thanks, >> >> Stephen >> >> >> >> >> >> >> >> >> >> On Thu, Aug 28, 2014 at 2:57 PM, Susanne Balle >> >> <sleipnir...@gmail.com> wrote: >> >> >> >> I would like to discuss the pros and >> >> cons of putting Octavia into the >> >> Neutron LBaaS incubator project right >> >> away. If it is going to be the >> >> reference implementation for LBaaS v 2 >> >> then I believe Octavia belong in >> >> Neutron LBaaS v2 incubator. >> >> >> >> >> >> The Pros: >> >> * Octavia is in Openstack incubation >> >> right away along with the lbaas v2 >> >> code. We do not have to apply for >> >> incubation later on. >> >> * As incubation project we have our >> >> own core and should be able ot commit >> >> our code >> >> * We are starting out as an OpenStack >> >> incubated project >> >> >> >> >> >> The Cons: >> >> * Not sure of the velocity of the >> >> project >> >> * Incubation not well defined. >> >> >> >> >> >> If Octavia starts as a standalone >> >> stackforge project we are assuming >> >> that it would be looked favorable on >> >> when time is to move it into incubated >> >> status. >> >> >> >> >> >> Susanne >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>_______________________________________________ >> >> OpenStack-dev mailing list >> >> OpenStack-dev@lists.openstack.org >> >> >> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> OpenStack-dev mailing list >> >> OpenStack-dev@lists.openstack.org >> >> >> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> >_______________________________________________ >> >OpenStack-dev mailing list >> >OpenStack-dev@lists.openstack.org >> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
