<div dir="ltr"><div>I 100% agree with what Brandon wrote below and that is why IMHO they go together and should be part of the same codebase.</div><div><br></div><div>Susanne</div><div><br></div><div>On Tue, Sep 2, 2014 at 1:12 AM, Brandon Logan <span dir="ltr"><<a href="mailto:brandon.logan@rackspace.com" target="_blank">brandon.logan@rackspace.com</a>></span> wrote:<br>
</div><div><br></div>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><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Sep 2, 2014 at 1:12 AM, Brandon Logan <span dir="ltr"><<a href="mailto:brandon.logan@rackspace.com" target="_blank">brandon.logan@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">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>
<div><div class="h5"><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>
</div></div>> Radware / A10 / etcappliances, not to an Openstack API layer<br>
<div><div class="h5">> 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>
> [Susanne] Ok now I am confused… But I agree with you that it<br>
> 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>
> [Susanne] Ok now I am confused… But I agree with you<br>
> 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>
> guessing….<br>
><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>
</div></div>> * Neutron incubator is the on-ramp for<br>
<div class="">> projects which should eventually<br>
> become a part of Neutron itself.<br>
</div>> * Projects which enter the Neutron<br>
<div class="">> 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>
</div>> * Neutron incubator projects effectively<br>
<div class="">> 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>
</div>> * It's already (informally?) agreed that<br>
<div class="">> 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>
</div>> * When the LBaaS component spins out of<br>
<div class="">> 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>
</div>> * The end-game for the above point is:<br>
<div class="">> 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>
</div>> * While its true that we would like<br>
<div class=""><div class="h5">> 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>
> 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>
><br>
><br>
><br>
</div></div><div class=""><div class="h5">> _______________________________________________<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>