[openstack-dev] [neutron][lbaas][octavia]
Susanne Balle
sleipnir012 at gmail.com
Tue Sep 2 14:34:35 UTC 2014
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.
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.
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.
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140902/97b108e2/attachment-0001.html>
More information about the OpenStack-dev
mailing list