[openstack-dev] [neutron][lbaas][octavia]
Phillip Toohill
phillip.toohill at RACKSPACE.COM
Tue Sep 2 20:28:26 UTC 2014
Slightly related, Hulu decides to play new shows Ive never watched
before when im barely watching it and I heard them calling an actresses
name that caught my attention.
http://the100.wikia.com/wiki/Octavia_Blake
Dont' think it'll affect the trademark or anything :P, just thought it
was interesting that im hearing this name more and more lately.
I'm sure theres another name for it, but ive dubbed this phenomenon the
'GTA effect'. Where once you find, see or hear something you begin to
find, see and hear more of it.
:)
On Tue, 2014-09-02 at 12:41 -0700, Stephen Balukoff wrote:
> Yep-- I put in the application at the mid-cycle summit. There were no
> obvious conflicts at the time, so I'd be surprised if the application
> isn't approved. But the USPTO takes months to process these things,
> so we might not know for a couple months still.
>
>
> Stephen
>
>
> On Tue, Sep 2, 2014 at 12:02 PM, Brandon Logan
> <brandon.logan at rackspace.com> wrote:
> 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
>
> _______________________________________________
> 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
More information about the OpenStack-dev
mailing list