[openstack-dev] [neutron][lbaas][octavia]
Susanne Balle
sleipnir012 at gmail.com
Tue Sep 2 16:06:33 UTC 2014
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 <dougw at 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 <sorlando at nicira.com>
>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Date: Tuesday, September 2, 2014 at 9:05 AM
>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at 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 <sleipnir012 at 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 <sorlando at nicira.com>
>> wrote:
>>
>>> Some more comments from me inline.
>>> Salvatore
>>>
>>>
>>> On 2 September 2014 11:06, Adam Harwell <adam.harwell at 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.logan at 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.harwell at 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 <sleipnir012 at gmail.com>
>>>> >> Reply-To: "OpenStack Development Mailing List (not for usage
>>>> >> questions)" <openstack-dev at lists.openstack.org>
>>>> >> Date: Friday, August 29, 2014 9:19 AM
>>>> >> To: "OpenStack Development Mailing List (not for usage
>>>> >> questions)" <openstack-dev at 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
>>>> >> <sbalukoff at 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
>>>> >> <sleipnir012 at 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 at lists.openstack.org
>>>> >>
>>>> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> _______________________________________________
>>>> >> OpenStack-dev mailing list
>>>> >> OpenStack-dev at lists.openstack.org
>>>> >>
>>>> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> >>
>>>> >>
>>>> >_______________________________________________
>>>> >OpenStack-dev mailing list
>>>> >OpenStack-dev at lists.openstack.org
>>>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140902/1a65daf2/attachment.html>
More information about the OpenStack-dev
mailing list