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