[openstack-dev] [neutron][lbaas][octavia]
Brandon Logan
brandon.logan at RACKSPACE.COM
Tue Sep 2 19:02:25 UTC 2014
Stephen actually has a trademark request in for Octavia. It apparently
was not trademarks prior to his request.
On Tue, 2014-09-02 at 20:28 +0200, Salvatore Orlando wrote:
> Inline.
> Salvatore
>
> On 2 September 2014 19:46, Stephen Balukoff <sbalukoff at bluebox.net>
> wrote:
> For what it's worth in this discussion, I agree that the
> possible futures of Octavia already discussed (where it lives,
> how it relates to Neutron LBaaS, etc.) are all possible. What
> actually happens here is going to depend both on the Octavia
> team, the Neutron team (especially when it comes to how the
> neutron-incubator is practically managed), and anyone else
> interested in contributing to these projects.
>
>
> Again, for now, I think it's most important to get involved,
> write code, and start delivering on the immediate, obvious
> things that need to be done for Octavia.
>
>
> Probably... at least we'll be speculating about something which
> actually exists.
>
>
>
> In my mind, there are too many unknowns to predict exactly
> where things will end up in the long run. About the only thing
> I am certain of is that everyone involving themselves in the
> Octavia project wants to see it become a part of OpenStack (in
> whatever way that happens), and that that will certainly not
> happen if we aren't able to build the operator-scale load
> balancer we all want.
>
>
> Beyond that, I don't see a whole lot of point to the
> speculation here. :/ (Maybe someone can enlighten me to this
> point?)
>
>
> I have speculated only to the extent that it was needed for me to
> understand what's the interface between the two things.
> Beyond that, I agree and have already pointed out that there is no
> urgency for prolonging this discussion, unless the lbaas and octavia
> team feel this will have a bearing on short term developments. I don't
> think so but I do not have the full picture.
>
>
> Talking about pointless things you might want to ensure the name
> 'octavia' is not trademarked before writing lots of code! Renames are
> painful and some openstack projects (like neutron and zaqar) know
> something about that.
>
>
>
>
> Stephen
>
>
>
>
> On Tue, Sep 2, 2014 at 9:40 AM, Brandon Logan
> <brandon.logan at rackspace.com> wrote:
> Hi Susanne,
>
> I believe the options for Octavia are:
> 1) Merge into the LBaaS tree (wherever LBaaS is)
> 2) Become its own openstack project
> 3) Remains in stackforge for eternity
>
> #1 Is dependent on these options
> 1) LBaaS V2 graduates from the incubator into Neutron.
> V1 is deprecated.
> 2) LBaaS V2 remains in incubator until it can be spun
> out. V1 in
> Neutron is deprecated.
> 3) LBaaS V2 is abandoned in the incubator and LBaaS V1
> remains. (An
> unlikely option)
>
> I don't see any other feasible options.
>
> On Tue, 2014-09-02 at 12:06 -0400, Susanne Balle
> wrote:
> > 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
> >
> >
> >
> > _______________________________________________
> > 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
>
>
>
>
>
> --
> Stephen Balukoff
> Blue Box Group, LLC
> (800)613-4305 x807
>
> _______________________________________________
> 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
More information about the OpenStack-dev
mailing list