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