<div dir="ltr"><div class="gmail_extra">Hi Susanne,</div><div class="gmail_extra"><br></div><div class="gmail_extra">I'm just trying to gain a good understanding of the situation here.</div><div class="gmail_extra">More comments and questions inline.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Salvatore<br><br><div class="gmail_quote">On 2 September 2014 16:34, Susanne Balle <span dir="ltr"><<a href="mailto:sleipnir012@gmail.com" target="_blank">sleipnir012@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Salvatore<div><br></div><div>Thanks for your clarification below around the blueprint.</div>
<div class=""><div><div><br></div><div><div style="font-family:arial,sans-serif;font-size:13px">> For LBaaS v2 therefore the relationship between it and Octavia should be the same as with any other</div>
<div style="font-family:arial,sans-serif;font-size:13px">> backend. I see Octavia has a blueprint for a "network driver" - and the derivable of that should definitely be</div><div style="font-family:arial,sans-serif;font-size:13px">
> part of the LBaaS project.</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">> For the rest, it would seem a bit strange to me if the LBaaS project incorporated a backend as well. After <br>
</div><div style="font-family:arial,sans-serif;font-size:13px">> all, LBaaS v1 did not incorporate haproxy!</div><div style="font-family:arial,sans-serif;font-size:13px">> Also, as Adam points out, Nova does not incorporate an Hypervisor.</div>
</div></div><div style="font-family:arial,sans-serif;font-size:13px"><br></div></div><div style="font-family:arial,sans-serif;font-size:13px">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.</div>
</div></blockquote><div><br></div><div>Indeed I said that it would have been initially tied to haproxy considering the blueprints currently defined for octavia, but I'm sure the solution could leverage nginx or something else in the future. </div>
<div><br></div><div>I think however it is correct to say that LBaaS v2 will have an Octavia driver on par with A10, radware, nestscaler and others.</div><div>(Correct me if I'm wrong) On the other hand Octavia, within its implementation, might use different drivers - for instance nginx or haproxy. And in theory it cannot be excluded that the same appliance might implement some vips using haproxy and others using nginx.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">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. </div>
</div></blockquote><div><br></div><div>What about this blueprint? <a href="https://blueprints.launchpad.net/octavia/+spec/neutron-network-driver">https://blueprints.launchpad.net/octavia/+spec/neutron-network-driver</a></div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">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.</div>
</div></blockquote><div><br></div><div>Octavia could be part of the lbaas service just like neutron has a set of agents which at the end of the day provide a L2/L3 network virtualization service. Personally I'm of the opinion that I would move that code in a separate repo which could be maintained by networking experts (I can barely plug an ethernet cable into a switch). But the current situation creates a case for Octavia inclusion in lbaas.</div>
<div><br></div><div>On the other hand one could also say that Octavia is the ML2 equivalent of LBaaS. The equivalence here is very loose. Octavia would be a service-VM framework for doing load balancing using a variety of drivers. The drivers ultimately are in charge of using backends like haproxy or nginx running on the service VM to implement lbaas configuration.</div>
<div>To avoid further discussion it might be better to steer away from discussing overlaps and synergies with the service VM project, at least for now.</div><div><br></div><div>I think the ability of having the Libra driver was discussed in the past. I do not know the details, but it seemed there was not a lot to gain from having a Neutron LBaaS driver pointing to libra (ie: it was much easier to just deploy libra instead of neutron lbaas).</div>
<div><br></div><div>Summarising, so far I haven't yet an opinion regarding where Octavia will sit.</div><div>Nevertheless I think this is a discussion that it's useful for the medium/long term - it does not seem to me that there is an urgency here.</div>
<div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Regards Susanne</div></div><div class=""><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, Sep 2, 2014 at 9:18 AM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><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">
<div>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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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><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>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
[blogan] "I think the best course of action is to get Octavia itself into<br>
<div>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>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><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>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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><br>
<br>
<br>
On 9/1/14 10:12 PM, "Brandon Logan" <<a href="mailto:brandon.logan@RACKSPACE.COM" target="_blank">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" target="_blank">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>>> 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" target="_blank">sleipnir012@gmail.com</a>><br>
>> Reply-To: "OpenStack Development Mailing List (not for usage<br>
>> questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">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" target="_blank">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>>> 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><div>>><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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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></div></div><br></div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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></blockquote></div><br></div>
</div></div><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></blockquote></div><br></div></div>