<div dir="ltr"><div><span style="font-family:arial,sans-serif;font-size:13px">Kyle,</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">This makes a lot of sense to me and is our favorite way to move forward.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Susanne</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><span style="font-family:arial,sans-serif;font-size:13px"><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">--------------------------------</span></div>To me what makes sense here is that we merge the Octavia code into the</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">neutron-incubator when the LBaaS V2 code is merged there. If the end</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">goal is to spin the LBaaS V2 stuff out into a separate git repository</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">and project (under the networking umbrella), this would allow for the</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">Octavia driver to be developed alongside the V2 API code, and in fact</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">help satisfy one of the requirements around Neutron incubation</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">graduation: Having a functional driver. And it also allows for the</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">driver to continue to live on next to the API.</span><br style="font-family:arial,sans-serif;font-size:13px"><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">What do people think about this?</span><br style="font-family:arial,sans-serif;font-size:13px"><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">Thanks,</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">Kyle</span><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Sep 2, 2014 at 3:52 PM, Kyle Mestery <span dir="ltr"><<a href="mailto:mestery@mestery.com" target="_blank">mestery@mestery.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Tue, Sep 2, 2014 at 1:28 PM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>> wrote:<br>
> Inline.<br>
> Salvatore<br>
><br>
> On 2 September 2014 19:46, Stephen Balukoff <<a href="mailto:sbalukoff@bluebox.net">sbalukoff@bluebox.net</a>> wrote:<br>
>><br>
>> For what it's worth in this discussion, I agree that the possible futures<br>
>> of Octavia already discussed (where it lives, how it relates to Neutron<br>
>> LBaaS, etc.) are all possible. What actually happens here is going to depend<br>
>> both on the Octavia team, the Neutron team (especially when it comes to how<br>
>> the neutron-incubator is practically managed), and anyone else interested in<br>
>> contributing to these projects.<br>
>><br>
>> Again, for now, I think it's most important to get involved, write code,<br>
>> and start delivering on the immediate, obvious things that need to be done<br>
>> for Octavia.<br>
><br>
><br>
> Probably... at least we'll be speculating about something which actually<br>
> exists.<br>
><br>
</div>To me what makes sense here is that we merge the Octavia code into the<br>
neutron-incubator when the LBaaS V2 code is merged there. If the end<br>
goal is to spin the LBaaS V2 stuff out into a separate git repository<br>
and project (under the networking umbrella), this would allow for the<br>
Octavia driver to be developed alongside the V2 API code, and in fact<br>
help satisfy one of the requirements around Neutron incubation<br>
graduation: Having a functional driver. And it also allows for the<br>
driver to continue to live on next to the API.<br>
<br>
What do people think about this?<br>
<br>
Thanks,<br>
Kyle<br>
<div><div class="h5"><br>
>><br>
>><br>
>> In my mind, there are too many unknowns to predict exactly where things<br>
>> will end up in the long run. About the only thing I am certain of is that<br>
>> everyone involving themselves in the Octavia project wants to see it become<br>
>> a part of OpenStack (in whatever way that happens), and that that will<br>
>> certainly not happen if we aren't able to build the operator-scale load<br>
>> balancer we all want.<br>
>><br>
>><br>
>> Beyond that, I don't see a whole lot of point to the speculation here. :/<br>
>> (Maybe someone can enlighten me to this point?)<br>
><br>
><br>
> I have speculated only to the extent that it was needed for me to understand<br>
> what's the interface between the two things.<br>
> Beyond that, I agree and have already pointed out that there is no urgency<br>
> for prolonging this discussion, unless the lbaas and octavia team feel this<br>
> will have a bearing on short term developments. I don't think so but I do<br>
> not have the full picture.<br>
><br>
> Talking about pointless things you might want to ensure the name 'octavia'<br>
> is not trademarked before writing lots of code! Renames are painful and some<br>
> openstack projects (like neutron and zaqar) know something about that.<br>
><br>
>><br>
>><br>
>> Stephen<br>
>><br>
>><br>
>><br>
>> On Tue, Sep 2, 2014 at 9:40 AM, Brandon Logan<br>
>> <<a href="mailto:brandon.logan@rackspace.com">brandon.logan@rackspace.com</a>> wrote:<br>
>>><br>
>>> Hi Susanne,<br>
>>><br>
>>> I believe the options for Octavia are:<br>
>>> 1) Merge into the LBaaS tree (wherever LBaaS is)<br>
>>> 2) Become its own openstack project<br>
>>> 3) Remains in stackforge for eternity<br>
>>><br>
>>> #1 Is dependent on these options<br>
>>> 1) LBaaS V2 graduates from the incubator into Neutron. V1 is deprecated.<br>
>>> 2) LBaaS V2 remains in incubator until it can be spun out. V1 in<br>
>>> Neutron is deprecated.<br>
>>> 3) LBaaS V2 is abandoned in the incubator and LBaaS V1 remains. (An<br>
>>> unlikely option)<br>
>>><br>
>>> I don't see any other feasible options.<br>
>>><br>
>>> On Tue, 2014-09-02 at 12:06 -0400, Susanne Balle wrote:<br>
>>> > Doug<br>
>>> ><br>
>>> ><br>
>>> > I agree with you but I need to understand the options. Susanne<br>
>>> ><br>
>>> ><br>
>>> > >> And I agree with Brandon’s sentiments. We need to get something<br>
>>> > built before I’m going to worry too<br>
>>> > >> much about where it should live. Is this a candidate to get sucked<br>
>>> > into LBaaS? Sure. Could the reverse<br>
>>> > >> happen? Sure. Let’s see how it develops.<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > On Tue, Sep 2, 2014 at 11:45 AM, Doug Wiegley <<a href="mailto:dougw@a10networks.com">dougw@a10networks.com</a>><br>
>>> > wrote:<br>
>>> > Hi all,<br>
>>> ><br>
>>> ><br>
>>> > > On the other hand one could also say that Octavia is the ML2<br>
>>> > equivalent of LBaaS. The equivalence here is very loose.<br>
>>> > Octavia would be a service-VM framework for doing load<br>
>>> > balancing using a variety of drivers. The drivers ultimately<br>
>>> > are in charge of using backends like haproxy or nginx running<br>
>>> > on the service VM to implement lbaas configuration.<br>
>>> ><br>
>>> ><br>
>>> > This, exactly. I think it’s much fairer to define Octavia as<br>
>>> > an LBaaS purpose-built service vm framework, which will use<br>
>>> > nova and haproxy initially to provide a highly scalable<br>
>>> > backend. But before we get into terminology misunderstandings,<br>
>>> > there are a bunch of different “drivers” at play here, exactly<br>
>>> > because this is a framework:<br>
>>> > * Neutron lbaas drivers – what we all know and love<br>
>>> > * Octavia’s “network driver” - this is a piece of glue<br>
>>> > that exists to hide internal calls we have to make<br>
>>> > into Neutron until clean interfaces exist. It might<br>
>>> > be a no-op in the case of an actual neutron lbaas<br>
>>> > driver, which could serve that function instead.<br>
>>> > * Octavia’s “vm driver” - this is a piece of glue<br>
>>> > between the octavia controller and the nova VMs that<br>
>>> > are doing the load balancing.<br>
>>> > * Octavia’s “compute driver” - you guessed it, an<br>
>>> > abstraction to Nova and its scheduler.<br>
>>> > Places that can be the “front-end” for Octavia:<br>
>>> > * Neutron LBaaS v2 driver<br>
>>> > * Neutron LBaaS v1 driver<br>
>>> > * It’s own REST API<br>
>>> > Things that could have their own VM drivers:<br>
>>> > * haproxy, running inside nova<br>
>>> > * Nginx, running inside nova<br>
>>> > * Anything else you want, running inside any hypervisor<br>
>>> > you want<br>
>>> > * Vendor soft appliances<br>
>>> > * Null-out the VM calls and go straight to some other<br>
>>> > backend? Sure, though I’m not sure I’d see the point.<br>
>>> > There are quite a few synergies with other efforts, and we’re<br>
>>> > monitoring them, but not waiting for any of them.<br>
>>> ><br>
>>> ><br>
>>> > And I agree with Brandon’s sentiments. We need to get<br>
>>> > something built before I’m going to worry too much about where<br>
>>> > it should live. Is this a candidate to get sucked into<br>
>>> > LBaaS? Sure. Could the reverse happen? Sure. Let’s see how<br>
>>> > it develops.<br>
>>> ><br>
>>> ><br>
>>> > Incidentally, we are currently having a debate over the use of<br>
>>> > the term “vm” (and “vm driver”) as the name to describe<br>
>>> > octavia’s backends. Feel free to chime in<br>
>>> > here: <a href="https://review.openstack.org/#/c/117701/" target="_blank">https://review.openstack.org/#/c/117701/</a><br>
>>> ><br>
>>> ><br>
>>> > Thanks,<br>
>>> > doug<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > From: Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>><br>
>>> ><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>
>>> ><br>
>>> > Date: Tuesday, September 2, 2014 at 9:05 AM<br>
>>> ><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>
>>> > Subject: Re: [openstack-dev] [neutron][lbaas][octavia]<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > Hi Susanne,<br>
>>> ><br>
>>> ><br>
>>> > I'm just trying to gain a good understanding of the situation<br>
>>> > here.<br>
>>> > More comments and questions inline.<br>
>>> ><br>
>>> ><br>
>>> > Salvatore<br>
>>> ><br>
>>> > On 2 September 2014 16:34, Susanne Balle<br>
>>> > <<a href="mailto:sleipnir012@gmail.com">sleipnir012@gmail.com</a>> wrote:<br>
>>> > Salvatore<br>
>>> ><br>
>>> ><br>
>>> > Thanks for your clarification below around the<br>
>>> > blueprint.<br>
>>> ><br>
>>> ><br>
>>> > > For LBaaS v2 therefore the relationship between it<br>
>>> > and Octavia should be the same as with any other<br>
>>> > > backend. I see Octavia has a blueprint for a<br>
>>> > "network driver" - and the derivable of that should<br>
>>> > definitely be<br>
>>> > > part of the LBaaS project.<br>
>>> ><br>
>>> ><br>
>>> > > For the rest, it would seem a bit strange to me if<br>
>>> > the LBaaS project incorporated a backend as well.<br>
>>> > After<br>
>>> ><br>
>>> > > all, LBaaS v1 did not incorporate haproxy!<br>
>>> > > Also, as Adam points out, Nova does not incorporate<br>
>>> > an Hypervisor.<br>
>>> ><br>
>>> ><br>
>>> > In my vision Octavia is a LBaaS framework that should<br>
>>> > not be tied to ha-proxy. The interfaces should be<br>
>>> > clean and at a high enough level that we can switch<br>
>>> > load-balancer. We should be able to switch the<br>
>>> > load-balancer to nginx so to me the analogy is more<br>
>>> > Octavia+LBaaSV2 == nova and hypervisor ==<br>
>>> > load-balancer.<br>
>>> ><br>
>>> ><br>
>>> > Indeed I said that it would have been initially tied to<br>
>>> > haproxy considering the blueprints currently defined for<br>
>>> > octavia, but I'm sure the solution could leverage nginx or<br>
>>> > something else in the future.<br>
>>> ><br>
>>> ><br>
>>> > I think however it is correct to say that LBaaS v2 will have<br>
>>> > an Octavia driver on par with A10, radware, nestscaler and<br>
>>> > others.<br>
>>> > (Correct me if I'm wrong) On the other hand Octavia, within<br>
>>> > its implementation, might use different drivers - for instance<br>
>>> > nginx or haproxy. And in theory it cannot be excluded that the<br>
>>> > same appliance might implement some vips using haproxy and<br>
>>> > others using nginx.<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > I am not sure the group is in agreement on the<br>
>>> > definition I just wrote. Also going back the<br>
>>> > definition of Octavia being a backend then I agree<br>
>>> > that we should write a blueprint to incorporate<br>
>>> > Octavia as a network driver.<br>
>>> ><br>
>>> ><br>
>>> > What about this blueprint?<br>
>>> ><br>
>>> > <a href="https://blueprints.launchpad.net/octavia/+spec/neutron-network-driver" target="_blank">https://blueprints.launchpad.net/octavia/+spec/neutron-network-driver</a><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > I guess I had always envisioned what we now call<br>
>>> > Octavia to be part of the LBaaS service itself and<br>
>>> > have ha-proxy, nginx be the drivers and not have the<br>
>>> > driver level be at the Octavia cut-over point, Given<br>
>>> > this new "design" I am now wondering why we didn't<br>
>>> > just write a driver for Libra and improved on Libra<br>
>>> > since to me that is the now the driver level we are<br>
>>> > discussing.<br>
>>> ><br>
>>> ><br>
>>> > Octavia could be part of the lbaas service just like neutron<br>
>>> > has a set of agents which at the end of the day provide a<br>
>>> > L2/L3 network virtualization service. Personally I'm of the<br>
>>> > opinion that I would move that code in a separate repo which<br>
>>> > could be maintained by networking experts (I can barely plug<br>
>>> > an ethernet cable into a switch). But the current situation<br>
>>> > creates a case for Octavia inclusion in lbaas.<br>
>>> ><br>
>>> ><br>
>>> > On the other hand one could also say that Octavia is the ML2<br>
>>> > equivalent of LBaaS. The equivalence here is very loose.<br>
>>> > Octavia would be a service-VM framework for doing load<br>
>>> > balancing using a variety of drivers. The drivers ultimately<br>
>>> > are in charge of using backends like haproxy or nginx running<br>
>>> > on the service VM to implement lbaas configuration.<br>
>>> > To avoid further discussion it might be better to steer away<br>
>>> > from discussing overlaps and synergies with the service VM<br>
>>> > project, at least for now.<br>
>>> ><br>
>>> ><br>
>>> > I think the ability of having the Libra driver was discussed<br>
>>> > in the past. I do not know the details, but it seemed there<br>
>>> > was not a lot to gain from having a Neutron LBaaS driver<br>
>>> > pointing to libra (ie: it was much easier to just deploy libra<br>
>>> > instead of neutron lbaas).<br>
>>> ><br>
>>> ><br>
>>> > Summarising, so far I haven't yet an opinion regarding where<br>
>>> > Octavia will sit.<br>
>>> > Nevertheless I think this is a discussion that it's useful for<br>
>>> > the medium/long term - it does not seem to me that there is an<br>
>>> > urgency here.<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > Regards Susanne<br>
>>> ><br>
>>> ><br>
>>> > On Tue, Sep 2, 2014 at 9:18 AM, Salvatore Orlando<br>
>>> > <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>> wrote:<br>
>>> > Some more comments from me inline.<br>
>>> ><br>
>>> > Salvatore<br>
>>> ><br>
>>> ><br>
>>> > On 2 September 2014 11:06, Adam Harwell<br>
>>> > <<a href="mailto:adam.harwell@rackspace.com">adam.harwell@rackspace.com</a>> wrote:<br>
>>> > I also agree with most of what Brandon<br>
>>> > said, though I am slightly<br>
>>> > concerned by the talk of merging<br>
>>> > Octavia and [Neutron-]LBaaS-v2<br>
>>> > codebases.<br>
>>> ><br>
>>> ><br>
>>> > Beyond all the reasons listed in this thread -<br>
>>> > merging codebases is always more difficult<br>
>>> > that what it seems!<br>
>>> > Also it seems to me there's not yet a clear<br>
>>> > path for LBaaS v2. Mostly because of the<br>
>>> > ongoing neutron incubator discussion.<br>
>>> > However in my opinion there are 3 paths (and I<br>
>>> > have no idea whether they might be applicable<br>
>>> > to Octavia as a standalone project).<br>
>>> > 1) Aim at becoming part of neutron via the<br>
>>> > incubator or any equivalent mechanisms<br>
>>> > 2) Evolve in loosely coupled fashion with<br>
>>> > neutron, but still be part of the networking<br>
>>> > program. (This means that LBaaS APIs will be<br>
>>> > part of Openstack Network APIs)<br>
>>> > 3) Evolve independently from neutron, and<br>
>>> > become part of a new program. I have no idea<br>
>>> > however whether there's enough material to<br>
>>> > have a "load balancing" program, and what<br>
>>> > would be the timeline for that.<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > [blogan] "I think the best course of<br>
>>> > action is to get Octavia itself into<br>
>>> > the same codebase as LBaaS (Neutron or<br>
>>> > spun out)."<br>
>>> ><br>
>>> > [sballe] "What I am trying to now<br>
>>> > understand is how we will move Octavia<br>
>>> > into the new LBaaS project?"<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > I didn't think that was ever going to<br>
>>> > be the plan -- sure, we'd have an<br>
>>> > Octavia driver that is part of the<br>
>>> > [Neutron-]LBaaS-v2 codebase (which<br>
>>> > Susanne did mention as well), but<br>
>>> > nothing more than that. The actual<br>
>>> > Octavia code would still be in its own<br>
>>> > project at the end of all of this,<br>
>>> > right? The driver code could be added<br>
>>> > to [Neutron-]LbaaS-v2 at any point<br>
>>> > once Octavia is mature enough to be<br>
>>> > used, just by submitting it as a CR, I<br>
>>> > believe. Doug might be able to comment<br>
>>> > on that, since he maintains the A10<br>
>>> > driver?<br>
>>> ><br>
>>> ><br>
>>> > From what I gathered so far Octavia is a fully<br>
>>> > fledged load balancing virtual appliance which<br>
>>> > (at least in its first iterations) will<br>
>>> > leverage haproxy.<br>
>>> > As also stated earlier in this thread it's a<br>
>>> > peer of commercial appliances from various<br>
>>> > vendors.<br>
>>> ><br>
>>> ><br>
>>> > For LBaaS v2 therefore the relationship<br>
>>> > between it and Octavia should be the same as<br>
>>> > with any other backend. I see Octavia has a<br>
>>> > blueprint for a "network driver" - and the<br>
>>> > derivable of that should definitely be part of<br>
>>> > the LBaaS project.<br>
>>> > For the rest, it would seem a bit strange to<br>
>>> > me if the LBaaS project incorporated a backend<br>
>>> > as well. After all, LBaaS v1 did not<br>
>>> > incorporate haproxy!<br>
>>> > Also, as Adam points out, Nova does not<br>
>>> > incorporate an Hypervisor.<br>
>>> ><br>
>>> ><br>
>>> > Also, I know I'm opening this same can<br>
>>> > of worms again, but I am curious<br>
>>> > about the HP mandate that "everything<br>
>>> > must be OpenStack" when it comes to<br>
>>> > Octavia. Since HP's offering would be<br>
>>> > "[Neutron-]LBaaS-v2", which happens<br>
>>> > to use Octavia as a backend, does it<br>
>>> > matter whether Octavia is an official<br>
>>> > OpenStack project**? If HP can offer<br>
>>> > Cloud Compute through Nova, and Nova<br>
>>> > uses some hypervisor like Xen or KVM<br>
>>> > (neither of which are a part of<br>
>>> > OpenStack), I am not sure how it is<br>
>>> > different to offer Cloud Load<br>
>>> > Balancing via [Neutron-]LBaaS-v2 which<br>
>>> > could be using a non-Openstack<br>
>>> > implementation for the backend. I<br>
>>> > don't see "Octavia needs to be in<br>
>>> > Openstack" as a blocker so long as the<br>
>>> > "LBaaS API" is part of OpenStack.<br>
>>> ><br>
>>> > **NOTE: I AM DEFINITELY STILL IN FAVOR<br>
>>> > OF OCTAVIA BEING AN OPENSTACK<br>
>>> > PROJECT. THIS IS JUST AN EXAMPLE FOR<br>
>>> > THE SAKE OF THIS PARTICULAR ARGUMENT.<br>
>>> > PLEASE DON'T THINK THAT I'M AGAINST<br>
>>> > OCTAVIA BEING OFFICIALLY INCUBATED!**<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>
>>> > On 9/1/14 10:12 PM, "Brandon Logan"<br>
>>> > <<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<br>
>>> > stackforge until it gets mature is<br>
>>> > >the best solution. I'm pretty sure<br>
>>> > we can all agree on that. Whenever<br>
>>> > >it is mature then, and only then, we<br>
>>> > should try to get it into openstack<br>
>>> > >one way or another. If Neutron LBaaS<br>
>>> > v2 is still incubated then it<br>
>>> > >should be relatively easy to get it<br>
>>> > in that codebase. If Neutron LBaaS<br>
>>> > >has already spun out, even easier for<br>
>>> > us. If we want Octavia to just<br>
>>> > >become an openstack project all its<br>
>>> > own then that will be the difficult<br>
>>> > >part.<br>
>>> > ><br>
>>> > >I think the best course of action is<br>
>>> > to get Octavia itself into the same<br>
>>> > >codebase as LBaaS (Neutron or spun<br>
>>> > out). They do go together, and the<br>
>>> > >maintainers will almost always be the<br>
>>> > same for both. This makes even<br>
>>> > >more sense when LBaaS is spun out<br>
>>> > into its own project.<br>
>>> > ><br>
>>> > >I really think all of the answers to<br>
>>> > these questions will fall into<br>
>>> > >place when we actually deliver a<br>
>>> > product that we are all wanting and<br>
>>> > >talking about delivering with<br>
>>> > Octavia. Once we prove that we can<br>
>>> > all<br>
>>> > >come together as a community and<br>
>>> > manage a product from inception to<br>
>>> > >maturity, we will then have the<br>
>>> > respect and trust to do what is best<br>
>>> > for<br>
>>> > >an Openstack LBaaS product.<br>
>>> > ><br>
>>> > >Thanks,<br>
>>> > >Brandon<br>
>>> > ><br>
>>> > >On Mon, 2014-09-01 at 10:18 -0400,<br>
>>> > Susanne Balle wrote:<br>
>>> > >> Kyle, Adam,<br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >> Based on this thread Kyle is<br>
>>> > suggesting the follow moving forward<br>
>>> > >> plan:<br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >> 1) We incubate Neutron LBaaS V2 in<br>
>>> > the ³Neutron² incubator ³and freeze<br>
>>> > >> LBaas V1.0²<br>
>>> > >> 2) ³Eventually² It graduates into a<br>
>>> > project under the networking<br>
>>> > >> program.<br>
>>> > >> 3) ³At that point² We deprecate<br>
>>> > Neutron LBaaS v1.<br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >> The words in ³xx³ are works I added<br>
>>> > to make sure I/We understand the<br>
>>> > >> whole picture.<br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >> And as Adam mentions: Octavia !=<br>
>>> > LBaaS-v2. Octavia is a peer to F5 /<br>
>>> > >> Radware / A10 / etc appliances<br>
>>> > which is a definition I agree with<br>
>>> > BTW.<br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >> What I am trying to now understand<br>
>>> > is how we will move Octavia into<br>
>>> > >> the new LBaaS project?<br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >> If we do it later rather than<br>
>>> > develop Octavia in tree under the new<br>
>>> > >> incubated LBaaS project when do we<br>
>>> > plan to bring it in-tree from<br>
>>> > >> Stackforge? Kilo? Later? When LBaaS<br>
>>> > is a separate project under the<br>
>>> > >> Networking program?<br>
>>> > ><br>
>>> > >><br>
>>> > >><br>
>>> > >> What are the criteria to bring a<br>
>>> > driver into the LBaaS project and<br>
>>> > >> what do we need to do to replace<br>
>>> > the existing reference driver? Maybe<br>
>>> > >> adding a software driver to LBaaS<br>
>>> > source tree is less of a problem<br>
>>> > >> than converting a whole project to<br>
>>> > an OpenStack project.<br>
>>> > ><br>
>>> > >><br>
>>> > >><br>
>>> > >> Again I am open to both directions<br>
>>> > I just want to make sure we<br>
>>> > >> understand why we are choosing to<br>
>>> > do one or the other and that our<br>
>>> > >> decision is based on data and not<br>
>>> > emotions.<br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >> I am assuming that keeping Octavia<br>
>>> > in Stackforge will increase the<br>
>>> > >> velocity of the project and allow<br>
>>> > us more freedom which is goodness.<br>
>>> > >> We just need to have a plan to make<br>
>>> > 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,<br>
>>> > Adam Harwell<br>
>>> > >> <<a href="mailto:adam.harwell@rackspace.com">adam.harwell@rackspace.com</a>> wrote:<br>
>>> > >> Only really have comments<br>
>>> > on two of your related points:<br>
>>> > >><br>
>>> > >><br>
>>> > >> [Susanne] To me Octavia is<br>
>>> > a driver so it is very hard to me<br>
>>> > >> to think of it as a<br>
>>> > standalone project. It needs the new<br>
>>> > >> Neutron LBaaS v2 to<br>
>>> > function which is why I think of them<br>
>>> > >> together. This of course<br>
>>> > can change since we can add whatever<br>
>>> > >> layers we want to Octavia.<br>
>>> > >><br>
>>> > >><br>
>>> > >> [Adam] I guess I've always<br>
>>> > shared Stephen's<br>
>>> > >> viewpoint ‹ Octavia !=<br>
>>> > LBaaS-v2. Octavia is a peer to F5 /<br>
>>> > >> Radware / A10 /<br>
>>> > etcappliances, not to an Openstack API<br>
>>> > layer<br>
>>> > >> like Neutron-LBaaS. It's a<br>
>>> > little tricky to clearly define<br>
>>> > >> this difference in<br>
>>> > conversation, and I have noticed that<br>
>>> > quite<br>
>>> > >> a few people are having the<br>
>>> > same issue differentiating. In a<br>
>>> > >> small group, having quite a<br>
>>> > few people not on the same page is<br>
>>> > >> a bit scary, so maybe we<br>
>>> > need to really sit down and map this<br>
>>> > >> out so everyone is together<br>
>>> > one way or the other.<br>
>>> > >><br>
>>> > >><br>
>>> ><br>
>>> > >> [Susanne] Ok now I am<br>
>>> > confusedŠ But I agree with you that it<br>
>>> > >> need to focus on our use<br>
>>> > cases. I remember us discussing<br>
>>> > >> Octavia being the refenece<br>
>>> > implementation for OpenStack LBaaS<br>
>>> > >> (whatever that is). Has<br>
>>> > that changed while I was on vacation?<br>
>>> > >><br>
>>> > >><br>
>>> > >> [Adam] I believe that<br>
>>> > having the Octavia "driver" (not the<br>
>>> > >> Octavia codebase itself,<br>
>>> > technically) become the reference<br>
>>> > >> implementation for<br>
>>> > Neutron-LBaaS is still the plan in my<br>
>>> > eyes.<br>
>>> > >> The Octavia Driver in<br>
>>> > Neutron-LBaaS is a separate bit of<br>
>>> > code<br>
>>> > >> from the actual Octavia<br>
>>> > project, similar to the way the A10<br>
>>> > >> driver is a separate bit of<br>
>>> > code from the A10 appliance. To do<br>
>>> > >> that though, we need<br>
>>> > Octavia to be fairly close to fully<br>
>>> > >> functional. I believe we<br>
>>> > can do this because even though the<br>
>>> > >> reference driver would then<br>
>>> > require an additional service to<br>
>>> > >> run, what it requires is<br>
>>> > still fully-open-source and (by way<br>
>>> > >> of our plan) available as<br>
>>> > 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<br>
>>> > <<a href="mailto:sleipnir012@gmail.com">sleipnir012@gmail.com</a>><br>
>>> > >> Reply-To: "OpenStack<br>
>>> > Development Mailing List (not for<br>
>>> > usage<br>
>>> > >> questions)"<br>
>>> > <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>>> > >> Date: Friday, August 29,<br>
>>> > 2014 9:19 AM<br>
>>> > >> To: "OpenStack Development<br>
>>> > Mailing List (not for usage<br>
>>> > >> questions)"<br>
>>> > <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>>> > >><br>
>>> > >> Subject: Re:<br>
>>> > [openstack-dev]<br>
>>> > [neutron][lbaas][octavia]<br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >> Stephen<br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >> See inline<br>
>>> > comments.<br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >> Susanne<br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> ><br>
>>> > -----------------------------------------<br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >> Susanne--<br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >> I think you are<br>
>>> > conflating the difference between<br>
>>> > >> "OpenStack<br>
>>> > incubation" and "Neutron incubator."<br>
>>> > These<br>
>>> > >> are two very<br>
>>> > different matters and should be<br>
>>> > treated<br>
>>> > >> separately. So,<br>
>>> > addressing each one individually:<br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >> "OpenStack<br>
>>> > Incubation"<br>
>>> > >><br>
>>> > >> I think this has<br>
>>> > been the end-goal of Octavia all<br>
>>> > >> along and continues<br>
>>> > to be the end-goal. Under this<br>
>>> > >> scenario, Octavia<br>
>>> > is its own stand-alone project with<br>
>>> > >> its own PTL and<br>
>>> > core developer team, its own<br>
>>> > >> governance, and<br>
>>> > should eventually become part of the<br>
>>> > >> integrated<br>
>>> > OpenStack release. No project ever<br>
>>> > starts<br>
>>> > >> out as "OpenStack<br>
>>> > incubated."<br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >> [Susanne] I totally<br>
>>> > agree that the end goal is for<br>
>>> > >> Neutron LBaaS to<br>
>>> > become its own incubated project. I<br>
>>> > >> did miss the nuance<br>
>>> > that was pointed out by Mestery in<br>
>>> > >> an earlier email<br>
>>> > that if a Neutron incubator project<br>
>>> > >> wants to become a<br>
>>> > separate project it will have to<br>
>>> > >> apply for<br>
>>> > incubation again or at that time. It<br>
>>> > was my<br>
>>> > >> understanding that<br>
>>> > such a Neutron incubated project<br>
>>> > >> would be<br>
>>> > grandfathered in but again we do not<br>
>>> > have<br>
>>> > >> much details on the<br>
>>> > process yet.<br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >> To me Octavia is a<br>
>>> > driver so it is very hard to me to<br>
>>> > >> think of it as a<br>
>>> > standalone project. It needs the new<br>
>>> > >> Neutron LBaaS v2 to<br>
>>> > function which is why I think of<br>
>>> > >> them together. This<br>
>>> > of course can change since we can<br>
>>> > >> add whatever layers<br>
>>> > we want to Octavia.<br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >> "Neutron Incubator"<br>
>>> > >><br>
>>> > >> This has only<br>
>>> > become a serious discussion in the<br>
>>> > last<br>
>>> > >> few weeks and has<br>
>>> > yet to land, so there are many<br>
>>> > >> assumptions about<br>
>>> > this which don't pan out (either<br>
>>> > >> because of<br>
>>> > purposeful design and governance<br>
>>> > decisions,<br>
>>> > >> or because of how<br>
>>> > this project actually ends up being<br>
>>> > >> implemented from a<br>
>>> > practical standpoint). But given<br>
>>> > >> the inherent<br>
>>> > limitations about making statements<br>
>>> > with<br>
>>> > >> so many unknowns,<br>
>>> > the following seem fairly clear from<br>
>>> > >> what has been<br>
>>> > shared so far:<br>
>>> > >><br>
>>> > >> · Neutron incubator<br>
>>> > is the on-ramp for projects which<br>
>>> > >> should eventually<br>
>>> > become a part of Neutron itself.<br>
>>> > >><br>
>>> > >> · Projects which<br>
>>> > enter the Neutron incubator on-ramp<br>
>>> > >> should be fairly<br>
>>> > close to maturity in their final<br>
>>> > >> form. I think the<br>
>>> > intent here is for them to live in<br>
>>> > >> incubator for 1 or<br>
>>> > 2 cycles before either being merged<br>
>>> > >> into Neutron core,<br>
>>> > or being ejected (as abandoned, or<br>
>>> > >> as a separate<br>
>>> > project).<br>
>>> > >><br>
>>> > >> · Neutron incubator<br>
>>> > projects effectively do not have<br>
>>> > >> their own PTL and<br>
>>> > core developer team, and do not have<br>
>>> > >> their own<br>
>>> > governance.<br>
>>> > >><br>
>>> > >> [Susanne] Ok I<br>
>>> > missed the last point. In an earlier<br>
>>> > >> discussion Mestery<br>
>>> > implied that an incubated project<br>
>>> > >> would have at least<br>
>>> > one or two of its own cores. Maybe<br>
>>> > >> that changed<br>
>>> > between now and then.<br>
>>> > >><br>
>>> > >> In addition we know<br>
>>> > the following about Neutron LBaaS<br>
>>> > >> and Octavia:<br>
>>> > >><br>
>>> > >> · It's already<br>
>>> > (informally?) agreed that the ultimate<br>
>>> > >> long-term place for<br>
>>> > a LBaaS solution is probably to be<br>
>>> > >> spun out into its<br>
>>> > own project, which might<br>
>>> > >> appropriately live<br>
>>> > under a yet-to-be-defined master<br>
>>> > >> "Networking"<br>
>>> > project. (This would make Neutron,<br>
>>> > LBaaS,<br>
>>> > >> VPNaaS, FWaaS, etc.<br>
>>> > effective "peer" projects under<br>
>>> > >> the Networking<br>
>>> > umbrella.) Since this "Networking"<br>
>>> > >> umbrella project<br>
>>> > has even less defined about it than<br>
>>> > >> Neutron incubator,<br>
>>> > it's impossible to know whether<br>
>>> > >> being a part of<br>
>>> > Neutron incubator would be of any<br>
>>> > >> benefit to Octavia<br>
>>> > (or, conversely, to Neutron<br>
>>> > >> incubator) at all<br>
>>> > as an on-ramp to becoming part of<br>
>>> > >> "Networking."<br>
>>> > Presumably, Octavia might fit well<br>
>>> > under<br>
>>> > >> the "Networking"<br>
>>> > umbrella-- but, again, with nothing<br>
>>> > >> defined there it's<br>
>>> > impossible to draw any reasonable<br>
>>> > >> conclusions at this<br>
>>> > time.<br>
>>> > >><br>
>>> > >> [Susanne] We are in<br>
>>> > agreement here. This was the<br>
>>> > >> reasons we had the<br>
>>> > ad-hoc meeting in Atlanta so get a<br>
>>> > >> feel for hw people<br>
>>> > felt if we made Neutron LBaaS its<br>
>>> > >> own project and<br>
>>> > also how we got an operator large<br>
>>> > >> scale LBaaS that<br>
>>> > fit most of our service provider<br>
>>> > >> requirements. I am<br>
>>> > just worried because you keep on<br>
>>> > >> talking of Octavia<br>
>>> > as a standaloe project. To me it is<br>
>>> > >> an extension of<br>
>>> > Neutron LBaaS or of a new LBaaS Š. I<br>
>>> > >> do not see us (==<br>
>>> > me) use Octavia in a non OpenStack<br>
>>> > >> context. And yes it<br>
>>> > is a driver that I am hoping we<br>
>>> > >> all expect to<br>
>>> > become the reference implementation<br>
>>> > for<br>
>>> > >> LBaaS.<br>
>>> > >><br>
>>> > >> · When the LBaaS<br>
>>> > component spins out of Neutron, it<br>
>>> > >> will more than<br>
>>> > likely not be Octavia. Octavia<br>
>>> > >> is intentionally<br>
>>> > less friendly to 3rd party load<br>
>>> > >> balancer vendors<br>
>>> > both because it's envisioned that<br>
>>> > >> Octavia would just<br>
>>> > be another implementation which<br>
>>> > >> lives along-side<br>
>>> > said 3rd party vendor products<br>
>>> > >> (plugging into a<br>
>>> > higher level LBaaS layer via a<br>
>>> > >> driver), and<br>
>>> > because we don't want to have to<br>
>>> > >> compromise certain<br>
>>> > design features of Octavia to meet<br>
>>> > >> the lowest common<br>
>>> > denominator 3rd party vendor<br>
>>> > >> product. (3rd party<br>
>>> > vendors are welcome, but we will<br>
>>> > >> not make design<br>
>>> > compromises to meet the needs of a<br>
>>> > >> proprietary<br>
>>> > product-- compatibility with available<br>
>>> > >> open-source<br>
>>> > products and standards trumps this.)<br>
>>> > >><br>
>>> ><br>
>>> > >> [Susanne] Ok now I<br>
>>> > am confusedŠ But I agree with you<br>
>>> > >> that it need to<br>
>>> > focus on our use cases. I remember us<br>
>>> > >> discussing Octavia<br>
>>> > being the refenece implementation<br>
>>> > >> for OpenStack LBaaS<br>
>>> > (whatever that is). Has that<br>
>>> > >> changed while I was<br>
>>> > on vacation?<br>
>>> > >><br>
>>> > >> The end-game for<br>
>>> > the above point is: In the future I<br>
>>> > >> see "Openstack<br>
>>> > LBaaS" (or whatever the project calls<br>
>>> > >> itself) being a<br>
>>> > separate but complimentary project to<br>
>>> > >> Octavia.<br>
>>> > >><br>
>>> > >> · While its true<br>
>>> > that we would like Octavia to become<br>
>>> > >> the reference<br>
>>> > implementation for Neutron LBaaS, we<br>
>>> > are<br>
>>> > >> nowhere near being<br>
>>> > able to deliver on that. Attempting<br>
>>> > >> to become a part of<br>
>>> > Neutron LBaaS right now is likely<br>
>>> > >> just to create<br>
>>> > frustration (and very little merged<br>
>>> > >> code) for both the<br>
>>> > Octavia and Neutron teams.<br>
>>> > >><br>
>>> > >> [Susanne] Agreed.<br>
>>> > >><br>
>>> > >> So given that the<br>
>>> > only code in Octavia right now are a<br>
>>> > >> few database<br>
>>> > migrations, we are very, very far away<br>
>>> > >> from being ready<br>
>>> > for either OpenStack incubation or<br>
>>> > >> the Neutron<br>
>>> > incubator project. I don't think it's<br>
>>> > very<br>
>>> > >> useful to be<br>
>>> > spending time right now worrying about<br>
>>> > >> either of these<br>
>>> > outcomes: We should be working on<br>
>>> > >> Octavia!<br>
>>> > >><br>
>>> > >> [Susanne] Agreed.<br>
>>> > You suggested we discuss this on the<br>
>>> > >> ML NOW. I wanted to<br>
>>> > wait until the summit given that<br>
>>> > >> we would have more<br>
>>> > info on Neutron incubation, etc. I<br>
>>> > >> haven¹t seen much<br>
>>> > written down on the Neutron<br>
>>> > >> incubator project<br>
>>> > so most of what we are doing is<br>
>>> ><br>
>>> > >> guessingŠ.<br>
>>> > >><br>
>>> > >> Please also<br>
>>> > understand: I realize that probably<br>
>>> > the<br>
>>> > >> reason you're<br>
>>> > asking this right now is because you<br>
>>> > >> have a mandate<br>
>>> > within your organization to use only<br>
>>> > >> "official"<br>
>>> > OpenStack branded components, and if<br>
>>> > >> Octavia doesn't<br>
>>> > fall within that category, you won't<br>
>>> > >> be able to use it.<br>
>>> > Of course everyone working on this<br>
>>> > >> project wants to<br>
>>> > make that happen too, so we're doing<br>
>>> > >> everything we can<br>
>>> > to make sure we don't jeopardize<br>
>>> > >> that possibility.<br>
>>> > And there are enough voices in this<br>
>>> > >> project that want<br>
>>> > that to happen, so I think if we<br>
>>> > >> strayed from the<br>
>>> > path to get there, there would be<br>
>>> > >> sufficient clangor<br>
>>> > over this that it would be hard to<br>
>>> > >> miss. But I don't<br>
>>> > think there's anyone at all at this<br>
>>> > >> time that can<br>
>>> > honestly give you a promise that<br>
>>> > Octavia<br>
>>> > >> definitely will be<br>
>>> > incubated and will definitely end<br>
>>> > >> up in the<br>
>>> > integrated OpenStack release.<br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >> If you want to<br>
>>> > increase the chances of that<br>
>>> > happening,<br>
>>> > >> please help push<br>
>>> > the project forward!<br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >> [Susanne] That is<br>
>>> > what HP is doing. Remember we were<br>
>>> > >> here from the<br>
>>> > 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,<br>
>>> > 2014 at 9:52 PM, Stephen Balukoff<br>
>>> > >><br>
>>> > <<a href="mailto:sbalukoff@bluebox.net">sbalukoff@bluebox.net</a>> wrote:<br>
>>> > >> Susanne--<br>
>>> > >><br>
>>> > >><br>
>>> > >> I think you<br>
>>> > are conflating the difference<br>
>>> > >> between<br>
>>> > "OpenStack incubation" and "Neutron<br>
>>> > >> incubator."<br>
>>> > These are two very different<br>
>>> > >> matters and<br>
>>> > should be treated separately. So,<br>
>>> > >> addressing<br>
>>> > each one individually:<br>
>>> > >><br>
>>> > >><br>
>>> > >> "OpenStack<br>
>>> > Incubation"<br>
>>> > >> I think<br>
>>> > this has been the end-goal of Octavia<br>
>>> > >> all along<br>
>>> > and continues to be the end-goal.<br>
>>> > >> Under this<br>
>>> > scenario, Octavia is its own<br>
>>> > >> stand-alone<br>
>>> > project with its own PTL and core<br>
>>> > >> developer<br>
>>> > team, its own governance, and should<br>
>>> > >> eventually<br>
>>> > become part of the integrated<br>
>>> > >> OpenStack<br>
>>> > release. No project ever starts out<br>
>>> > >> as<br>
>>> > "OpenStack incubated."<br>
>>> > >><br>
>>> > >><br>
>>> > >> "Neutron<br>
>>> > Incubator"<br>
>>> > >> This has<br>
>>> > only become a serious discussion in<br>
>>> > >> the last<br>
>>> > few weeks and has yet to land, so<br>
>>> > >> there are<br>
>>> > many assumptions about this which<br>
>>> > >> don't pan<br>
>>> > out (either because of purposeful<br>
>>> > >> design and<br>
>>> > governance decisions, or because of<br>
>>> > >> how this<br>
>>> > project actually ends up being<br>
>>> > >> implemented<br>
>>> > from a practical standpoint). But<br>
>>> > >> given the<br>
>>> > inherent limitations about making<br>
>>> > >> statements<br>
>>> > with so many unknowns, the<br>
>>> > >> following<br>
>>> > seem fairly clear from what has been<br>
>>> > >> shared so<br>
>>> > far:<br>
>>> > >> *<br>
>>> > Neutron incubator is the on-ramp for<br>
>>> > >><br>
>>> > projects which should eventually<br>
>>> > >><br>
>>> > become a part of Neutron itself.<br>
>>> > >> *<br>
>>> > Projects which enter the Neutron<br>
>>> > >><br>
>>> > incubator on-ramp should be fairly<br>
>>> > >><br>
>>> > close to maturity in their final<br>
>>> > form.<br>
>>> > >> I<br>
>>> > think the intent here is for them to<br>
>>> > >><br>
>>> > live in incubator for 1 or 2 cycles<br>
>>> > >><br>
>>> > before either being merged into<br>
>>> > >><br>
>>> > Neutron core, or being ejected (as<br>
>>> > >><br>
>>> > abandoned, or as a separate project).<br>
>>> > >> *<br>
>>> > Neutron incubator projects effectively<br>
>>> > >> do<br>
>>> > not have their own PTL and core<br>
>>> > >><br>
>>> > developer team, and do not have their<br>
>>> > >> own<br>
>>> > governance.<br>
>>> > >> In addition<br>
>>> > we know the following about<br>
>>> > >> Neutron<br>
>>> > LBaaS and Octavia:<br>
>>> > >> *<br>
>>> > It's already (informally?) agreed that<br>
>>> > >> the<br>
>>> > ultimate long-term place for a<br>
>>> > >><br>
>>> > LBaaS solution is probably to be spun<br>
>>> > >> out<br>
>>> > into its own project, which might<br>
>>> > >><br>
>>> > appropriately live under a<br>
>>> > >><br>
>>> > yet-to-be-defined master "Networking"<br>
>>> > >><br>
>>> > project. (This would make Neutron,<br>
>>> > >><br>
>>> > LBaaS, VPNaaS, FWaaS, etc. effective<br>
>>> > >><br>
>>> > "peer" projects under the Networking<br>
>>> > >><br>
>>> > umbrella.) Since this "Networking"<br>
>>> > >><br>
>>> > umbrella project has even less<br>
>>> > defined<br>
>>> > >><br>
>>> > about it than Neutron incubator, it's<br>
>>> > >><br>
>>> > impossible to know whether being a<br>
>>> > >><br>
>>> > part of Neutron incubator would be of<br>
>>> > >> any<br>
>>> > benefit to Octavia (or,<br>
>>> > >><br>
>>> > conversely, to Neutron incubator) at<br>
>>> > >> all<br>
>>> > as an on-ramp to becoming part of<br>
>>> > >><br>
>>> > "Networking." Presumably, Octavia<br>
>>> > >><br>
>>> > might fit well under the "Networking"<br>
>>> > >><br>
>>> > umbrella-- but, again, with nothing<br>
>>> > >><br>
>>> > defined there it's impossible to draw<br>
>>> > >> any<br>
>>> > reasonable conclusions at this<br>
>>> > >><br>
>>> > time.<br>
>>> > >> *<br>
>>> > When the LBaaS component spins out of<br>
>>> > >><br>
>>> > Neutron, it will more than likely not<br>
>>> > >> be<br>
>>> > Octavia. Octavia is intentionally<br>
>>> > >><br>
>>> > less friendly to 3rd party load<br>
>>> > >><br>
>>> > balancer vendors both because it's<br>
>>> > >><br>
>>> > envisioned that Octavia would just be<br>
>>> > >><br>
>>> > another implementation which lives<br>
>>> > >><br>
>>> > along-side said 3rd party vendor<br>
>>> > >><br>
>>> > products (plugging into a higher<br>
>>> > level<br>
>>> > >><br>
>>> > LBaaS layer via a driver), and<br>
>>> > because<br>
>>> > >> we<br>
>>> > don't want to have to compromise<br>
>>> > >><br>
>>> > certain design features of Octavia to<br>
>>> > >><br>
>>> > meet the lowest common denominator<br>
>>> > 3rd<br>
>>> > >><br>
>>> > party vendor product. (3rd party<br>
>>> > >><br>
>>> > vendors are welcome, but we will not<br>
>>> > >><br>
>>> > make design compromises to meet the<br>
>>> > >><br>
>>> > needs of a proprietary product--<br>
>>> > >><br>
>>> > compatibility with available<br>
>>> > >><br>
>>> > open-source products and standards<br>
>>> > >><br>
>>> > trumps this.)<br>
>>> > >> * The<br>
>>> > end-game for the above point is:<br>
>>> > >> In<br>
>>> > the future I see "Openstack<br>
>>> > >><br>
>>> > LBaaS" (or whatever the project calls<br>
>>> > >><br>
>>> > itself) being a separate but<br>
>>> > >><br>
>>> > complimentary project to Octavia.<br>
>>> > >> *<br>
>>> > While its true that we would like<br>
>>> > >><br>
>>> > Octavia to become the reference<br>
>>> > >><br>
>>> > implementation for Neutron LBaaS, we<br>
>>> > >> are<br>
>>> > nowhere near being able to deliver<br>
>>> > >> on<br>
>>> > that. Attempting to become a part<br>
>>> > >> of<br>
>>> > Neutron LBaaS right now is likely<br>
>>> > >><br>
>>> > just to create frustration (and very<br>
>>> > >><br>
>>> > little merged code) for both the<br>
>>> > >><br>
>>> > Octavia and Neutron teams.<br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >> So given<br>
>>> > that the only code in Octavia right<br>
>>> > >> now are a<br>
>>> > few database migrations, we are<br>
>>> > >> very, very<br>
>>> > far away from being ready for<br>
>>> > >> either<br>
>>> > OpenStack incubation or the Neutron<br>
>>> > >> incubator<br>
>>> > project. I don't think it's very<br>
>>> > >> useful to<br>
>>> > be spending time right now worrying<br>
>>> > >> about<br>
>>> > either of these outcomes: We should<br>
>>> > be<br>
</div></div>>>> > >> working on<br>
>>> > Octavia!<br>
<div><div class="h5">>>> > >><br>
>>> > >><br>
>>> > >> Please also<br>
>>> > understand: I realize that<br>
>>> > >> probably<br>
>>> > the reason you're asking this right<br>
>>> > >> now is<br>
>>> > because you have a mandate within your<br>
>>> > >><br>
>>> > organization to use only "official"<br>
>>> > OpenStack<br>
>>> > >> branded<br>
>>> > components, and if Octavia doesn't<br>
>>> > >> fall within<br>
>>> > that category, you won't be able<br>
>>> > >> to use it.<br>
>>> > Of course everyone working on this<br>
>>> > >> project<br>
>>> > wants to make that happen too, so<br>
>>> > >> we're doing<br>
>>> > everything we can to make sure we<br>
>>> > >> don't<br>
>>> > jeopardize that possibility. And there<br>
>>> > >> are enough<br>
>>> > voices in this project that want<br>
>>> > >> that to<br>
>>> > happen, so I think if we strayed from<br>
>>> > >> the path to<br>
>>> > get there, there would be<br>
>>> > >> sufficient<br>
>>> > clangor over this that it would be<br>
>>> > >> hard to<br>
>>> > miss. But I don't think there's anyone<br>
>>> > >> at all at<br>
>>> > this time that can honestly give you<br>
>>> > >> a promise<br>
>>> > that Octavia definitely will be<br>
>>> > >> incubated<br>
>>> > and will definitely end up in the<br>
>>> > >> integrated<br>
>>> > OpenStack release.<br>
>>> > >><br>
>>> > >><br>
>>> > >> If you want<br>
>>> > to increase the chances of that<br>
>>> > >> happening,<br>
>>> > please help push the project<br>
>>> > >> forward!<br>
>>> > >><br>
>>> > >><br>
</div></div><div class="">>>> > >> Thanks,<br>
>>> > >> Stephen<br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >> On Thu, Aug<br>
</div><div><div class="h5">>>> > 28, 2014 at 2:57 PM, Susanne Balle<br>
>>> > >><br>
>>> > <<a href="mailto:sleipnir012@gmail.com">sleipnir012@gmail.com</a>> wrote:<br>
>>> > >><br>
>>> > >> I<br>
>>> > would like to discuss the pros and<br>
>>> > >><br>
>>> > cons of putting Octavia into the<br>
>>> > >><br>
>>> > Neutron LBaaS incubator project right<br>
>>> > >><br>
>>> > away. If it is going to be the<br>
>>> > >><br>
>>> > reference implementation for LBaaS v<br>
>>> > 2<br>
>>> > >><br>
>>> > then I believe Octavia belong in<br>
>>> > >><br>
>>> > Neutron LBaaS v2 incubator.<br>
>>> > >><br>
>>> > >><br>
>>> > >> The<br>
>>> > Pros:<br>
>>> > >> *<br>
>>> > Octavia is in Openstack incubation<br>
>>> > >><br>
>>> > right away along with the lbaas v2<br>
>>> > >><br>
>>> > code. We do not have to apply for<br>
>>> > >><br>
>>> > incubation later on.<br>
>>> > >> *<br>
>>> > As incubation project we have our<br>
>>> > >> own<br>
>>> > core and should be able ot commit<br>
>>> > >> our<br>
>>> > code<br>
>>> > >> *<br>
>>> > We are starting out as an OpenStack<br>
>>> > >><br>
>>> > incubated project<br>
>>> > >><br>
>>> > >><br>
>>> > >> The<br>
>>> > Cons:<br>
>>> > >> *<br>
</div></div>>>> > Not sure of the velocity of the<br>
>>> > >><br>
>>> > project<br>
<div class="HOEnZb"><div class="h5">>>> > >> *<br>
>>> > Incubation not well defined.<br>
>>> > >><br>
>>> > >><br>
>>> > >> If<br>
>>> > Octavia starts as a standalone<br>
>>> > >><br>
>>> > stackforge project we are assuming<br>
>>> > >><br>
>>> > that it would be looked favorable on<br>
>>> > >><br>
>>> > when time is to move it into<br>
>>> > incubated<br>
>>> > >><br>
>>> > status.<br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > Susanne<br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> > >><br>
>>> ><br>
>>> > >>_______________________________________________<br>
>>> > >><br>
>>> > OpenStack-dev mailing list<br>
>>> > >><br>
>>> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> > >><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>
>>> ><br>
>>> > _______________________________________________<br>
>>> > >><br>
>>> > OpenStack-dev mailing list<br>
>>> > >><br>
>>> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> > >><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>
>>> > >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>
>>> > 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>
>>> > 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>
>>> > 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>
>>> > 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>
>>> > 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>
>>> 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>
</div></div><div class="im HOEnZb">>> --<br>
>> Stephen Balukoff<br>
>> Blue Box Group, LLC<br>
>> (800)613-4305 x807<br>
>><br>
</div><div class="HOEnZb"><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>
> _______________________________________________<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>