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