[openstack-dev] [Neutron] Implementing new LBaaS API
Salvatore Orlando
sorlando at nicira.com
Mon Jun 16 14:24:04 UTC 2014
>From a few chats I had on IRC it seems some of the teams that are now
joining the load balancing effort are confident to be able to build a
standalone, production-grade service for the juno release; also I read this
email post [1], which points to the etherpad [2]
So, since I've been missing the lbaas meeting recently I probably wrongly
deducted it was a done deal.
[1] http://lists.openstack.org/pipermail/openstack/2014-June/007677.html
[2] https://etherpad.openstack.org/p/LBaaS_project_name_vote
On 16 June 2014 15:54, Kyle Mestery <mestery at noironetworks.com> wrote:
> On Mon, Jun 16, 2014 at 2:27 AM, Eugene Nikanorov
> <enikanorov at mirantis.com> wrote:
> > Salvatore,
> >
> >> Also - since it seems to me that there is also consensus regarding
> having
> >> load balancing move away into a separate project
> > To me it seems that there was no such a consensus; core team members were
> > advocating keeping lbaas within neutron.
> >
> In the short term, yes. But longer term, we'll reevaluate the
> viability of moving LBaaS out of Neutron into it's own incubated
> project, likely under the "Networking" program.
>
> Thanks,
> Kyle
>
> > Thanks,
> > Eugene.
> >
> >
> > On Mon, Jun 16, 2014 at 2:23 AM, Brandon Logan <
> brandon.logan at rackspace.com>
> > wrote:
> >>
> >> Thank you Salvatore for your feedback.
> >>
> >> Comments in-line.
> >>
> >> On Sun, 2014-06-15 at 23:26 +0200, Salvatore Orlando wrote:
> >> > Regarding the two approaches outlines in the top post, I found out
> >> > that the bullet "This is API versioning done the wrong way" appears in
> >> > both approaches.
> >> > Is this a mistake or intentional?
> >>
> >> No it was intentional. In my opinion they are both the wrong way. It
> >> would be best to be able to do a version at the resource layer but we
> >> can't since lbaas is a part of Neutron and its versions is directly tied
> >> to Neutron's. Another possibility is to have the resource look like:
> >>
> >> http(s)://neutron.endpoint/v2/lbaas/v2
> >>
> >> This looks very odd to me though and sets a bad precedent. That is just
> >> my opinion though. So I wouldn't call this the right way either. Thus,
> >> I do not know of a "right" way to do this other than choosing the right
> >> "alternative" way.
> >>
> >> >
> >> >
> >> > From what I gather, the most reasonable approach appears to be
> >> > starting with a clean slate, which means having a new API living side
> >> > by side with the old one.
> >> > I think the naming collision issues should probably be solved using
> >> > distinct namespaces for the two API (the old one has /v2/lbaas as a
> >> > URI prefix I think, I have hardly any idea about what namespace the
> >> > new one should have)
> >> >
> >>
> >> I'm in agreement with you as well. The old one has /v2/lb as the prefix.
> >> I figured the new one could be /v2/lbaas which I think works out well.
> >>
> >> Another thing to consider that I did not think about in my original
> >> message is that a whole new load balancing agent will have to be created
> >> as well since its code is written with the pool being the root object.
> >> So that should be taken into consideration. So to be perfectly clear,
> >> starting with a clean slate would involve the following:
> >>
> >> 1. New loadbalancer extension
> >> 2. New loadbalancer plugin
> >> 3. New lbaas_agentscheduler extension
> >> 4. New agent_scheduler plugin.
> >>
> >> Also, I don't believe doing this would allow the two to be deployed at
> >> the same time. I believe the setup.cfg file would have to be modified
> >> to point to the new plugins. I could be wrong about that though.
> >>
> >> >
> >> > Finally, about deprecation - I see it's been agreed to deprecate the
> >> > current API in Juno.
> >> > I think this is not the right way of doing things. The limits of the
> >> > current API are pretty much universally agreed; on the other hand, it
> >> > is generally not advisable to deprecate an old API in favour of the
> >> > new one at the first iteration such API is published. My preferred
> >> > strategy would be to introduce the new API as experimental in the Juno
> >> > release, so that in can be evaluated, apply any feedback and consider
> >> > for promoting in K - and contextually deprecate the old API.
> >> >
> >> >
> >> > As there is quite a radical change between the old and the new model,
> >> > keeping the old API indefinitely is a maintenance burden we probably
> >> > can't afford, and I would therefore propose complete removal one
> >> > release cycle after deprecation. Also - since it seems to me that
> >> > there is also consensus regarding having load balancing move away into
> >> > a separate project so that it would not be tied anymore to the
> >> > networking program, the old API is pretty much just dead weight.
> >> >
> >> > Salvatore
> >>
> >> Good idea on that. I'll bring this up with everyone at the hackathon
> >> this week if it is not already on the table.
> >>
> >> Thanks again for your feedback.
> >>
> >> Brandon
> >> >
> >> >
> >> > On 11 June 2014 18:01, Kyle Mestery <mestery at noironetworks.com>
> wrote:
> >> > I spoke to Mark McClain about this yesterday, I'll see if I
> >> > can get
> >> > him to join the LBaaS team meeting tomorrow so between he and
> >> > I we can
> >> > close on this with the LBaaS team.
> >> >
> >> > On Wed, Jun 11, 2014 at 10:57 AM, Susanne Balle
> >> > <sleipnir012 at gmail.com> wrote:
> >> > > Do we know who has an opinion? If so maybe we can reach out
> >> > to them directly
> >> > > and ask them to comment.
> >> > >
> >> > >
> >> > > On Tue, Jun 10, 2014 at 6:44 PM, Brandon Logan
> >> > <brandon.logan at rackspace.com>
> >> > > wrote:
> >> > >>
> >> > >> Well we got a few opinions, but not enough understanding of
> >> > the two
> >> > >> options to make an informed decision. It was requested
> >> > that the core
> >> > >> reviewers respond to this thread with their opinions.
> >> > >>
> >> > >> Thanks,
> >> > >> Brandon
> >> > >>
> >> > >> On Tue, 2014-06-10 at 13:22 -0700, Stephen Balukoff wrote:
> >> > >> > Yep, I'd like to know here, too-- as knowing the answer
> >> > to this
> >> > >> > unblocks implementation work for us.
> >> > >> >
> >> > >> >
> >> > >> > On Tue, Jun 10, 2014 at 12:38 PM, Brandon Logan
> >> > >> > <brandon.logan at rackspace.com> wrote:
> >> > >> > Any core neutron people have a chance to give
> >> > their opinions
> >> > >> > on this
> >> > >> > yet?
> >> > >> >
> >> > >> > Thanks,
> >> > >> > Brandon
> >> > >> >
> >> > >> > On Thu, 2014-06-05 at 15:28 +0000, Buraschi,
> >> > Andres wrote:
> >> > >> > > Thanks, Kyle. Great.
> >> > >> > >
> >> > >> > > -----Original Message-----
> >> > >> > > From: Kyle Mestery
> >> > [mailto:mestery at noironetworks.com]
> >> > >> > > Sent: Thursday, June 05, 2014 11:27 AM
> >> > >> > > To: OpenStack Development Mailing List (not for
> >> > usage
> >> > >> > questions)
> >> > >> > > Subject: Re: [openstack-dev] [Neutron]
> >> > Implementing new
> >> > >> > LBaaS API
> >> > >> > >
> >> > >> > > On Wed, Jun 4, 2014 at 4:27 PM, Brandon Logan
> >> > >> > <brandon.logan at rackspace.com> wrote:
> >> > >> > > > Hi Andres,
> >> > >> > > > I've assumed (and we know how assumptions
> >> > work) that the
> >> > >> > deprecation
> >> > >> > > > would take place in Juno and after a cyle or
> >> > two it would
> >> > >> > totally be
> >> > >> > > > removed from the code. Even if #1 is the way
> >> > to go, the
> >> > >> > old /vips
> >> > >> > > > resource would be deprecated in favor
> >> > of /loadbalancers
> >> > >> > and /listeners.
> >> > >> > > >
> >> > >> > > > I agree #2 is cleaner, but I don't want to
> >> > start on an
> >> > >> > implementation
> >> > >> > > > (though I kind of already have) that will
> >> > fail to be
> >> > >> > merged in because
> >> > >> > > > of the strategy. The strategies are pretty
> >> > different so
> >> > >> > one needs to
> >> > >> > > > be decided on.
> >> > >> > > >
> >> > >> > > > As for where LBaaS is intended to end up, I
> >> > don't want to
> >> > >> > speak for
> >> > >> > > > Kyle, so this is my understanding; It will
> >> > end up outside
> >> > >> > of the
> >> > >> > > > Neutron code base but Neutron and LBaaS and
> >> > other services
> >> > >> > will all
> >> > >> > > > fall under a Networking (or Network)
> >> > program. That is my
> >> > >> > > > understanding and I could be totally wrong.
> >> > >> > > >
> >> > >> > > That's my understanding as well, I think
> >> > Brandon worded it
> >> > >> > perfectly.
> >> > >> > >
> >> > >> > > > Thanks,
> >> > >> > > > Brandon
> >> > >> > > >
> >> > >> > > > On Wed, 2014-06-04 at 20:30 +0000, Buraschi,
> >> > Andres wrote:
> >> > >> > > >> Hi Brandon, hi Kyle!
> >> > >> > > >> I'm a bit confused about the deprecation
> >> > (btw, thanks for
> >> > >> > sending this Brandon!), as I (wrongly) assumed #1
> >> > would be the
> >> > >> > chosen path for the new API implementation. I
> >> > understand the
> >> > >> > proposal and #2 sounds actually cleaner.
> >> > >> > > >>
> >> > >> > > >> Just out of curiosity, Kyle, where is LBaaS
> >> > functionality
> >> > >> > intended to end up, if long-term plans are to
> >> > remove it from
> >> > >> > Neutron?
> >> > >> > > >>
> >> > >> > > >> (Nit question, I must clarify)
> >> > >> > > >>
> >> > >> > > >> Thank you!
> >> > >> > > >> Andres
> >> > >> > > >>
> >> > >> > > >> -----Original Message-----
> >> > >> > > >> From: Brandon Logan
> >> > [mailto:brandon.logan at RACKSPACE.COM]
> >> > >> > > >> Sent: Wednesday, June 04, 2014 2:18 PM
> >> > >> > > >> To: openstack-dev at lists.openstack.org
> >> > >> > > >> Subject: Re: [openstack-dev] [Neutron]
> >> > Implementing new
> >> > >> > LBaaS API
> >> > >> > > >>
> >> > >> > > >> Thanks for your feedback Kyle. I will be at
> >> > that meeting
> >> > >> > on Monday.
> >> > >> > > >>
> >> > >> > > >> Thanks,
> >> > >> > > >> Brandon
> >> > >> > > >>
> >> > >> > > >> On Wed, 2014-06-04 at 11:54 -0500, Kyle
> >> > Mestery wrote:
> >> > >> > > >> > On Tue, Jun 3, 2014 at 3:01 PM, Brandon
> >> > Logan
> >> > >> > > >> > <brandon.logan at rackspace.com> wrote:
> >> > >> > > >> > > This is an LBaaS topic bud I'd like to
> >> > get some
> >> > >> > Neutron Core
> >> > >> > > >> > > members to give their opinions on this
> >> > matter so I've
> >> > >> > just
> >> > >> > > >> > > directed this to Neutron proper.
> >> > >> > > >> > >
> >> > >> > > >> > > The design for the new API and object
> >> > model for LBaaS
> >> > >> > needs to be
> >> > >> > > >> > > locked down before the hackathon in a
> >> > couple of weeks
> >> > >> > and there
> >> > >> > > >> > > are some questions that need answered.
> >> > This is
> >> > >> > pretty urgent to
> >> > >> > > >> > > come on to a decision on and to get a
> >> > clear strategy
> >> > >> > defined so
> >> > >> > > >> > > we can actually do real code during the
> >> > hackathon
> >> > >> > instead of
> >> > >> > > >> > > wasting some of that valuable time
> >> > discussing this.
> >> > >> > > >> > >
> >> > >> > > >> > >
> >> > >> > > >> > > Implementation must be backwards
> >> > compatible
> >> > >> > > >> > >
> >> > >> > > >> > > There are 2 ways that have come up on
> >> > how to do this:
> >> > >> > > >> > >
> >> > >> > > >> > > 1) New API and object model are created
> >> > in the same
> >> > >> > extension and
> >> > >> > > >> > > plugin as the old. Any API requests
> >> > structured for
> >> > >> > the old API
> >> > >> > > >> > > will be translated/adapted to the into
> >> > the new object
> >> > >> > model.
> >> > >> > > >> > > PROS:
> >> > >> > > >> > > -Only one extension and plugin
> >> > >> > > >> > > -Mostly true backwards compatibility -Do
> >> > not have to
> >> > >> > rename
> >> > >> > > >> > > unchanged resources and models
> >> > >> > > >> > > CONS:
> >> > >> > > >> > > -May end up being confusing to an
> >> > end-user.
> >> > >> > > >> > > -Separation of old api and new api is
> >> > less clear
> >> > >> > -Deprecating and
> >> > >> > > >> > > removing old api and object model will
> >> > take a bit
> >> > >> > more work -This
> >> > >> > > >> > > is basically API versioning the wrong
> >> > way
> >> > >> > > >> > >
> >> > >> > > >> > > 2) A new extension and plugin are
> >> > created for the new
> >> > >> > API and
> >> > >> > > >> > > object model. Each API would live side
> >> > by side. New
> >> > >> > API would
> >> > >> > > >> > > need to have different names for
> >> > resources and object
> >> > >> > models from
> >> > >> > > >> > > Old API resources and object models.
> >> > >> > > >> > > PROS:
> >> > >> > > >> > > -Clean demarcation point between old and
> >> > new -No
> >> > >> > translation
> >> > >> > > >> > > layer needed -Do not need to modify
> >> > existing API and
> >> > >> > object
> >> > >> > > >> > > model, no new bugs -Drivers do not need
> >> > to be
> >> > >> > immediately
> >> > >> > > >> > > modified -Easy to deprecate and remove
> >> > old API and
> >> > >> > object model
> >> > >> > > >> > > later
> >> > >> > > >> > > CONS:
> >> > >> > > >> > > -Separate extensions and object model
> >> > will be
> >> > >> > confusing to
> >> > >> > > >> > > end-users -Code reuse by copy paste
> >> > since old
> >> > >> > extension and
> >> > >> > > >> > > plugin will be deprecated and removed.
> >> > >> > > >> > > -This is basically API versioning the
> >> > wrong way
> >> > >> > > >> > >
> >> > >> > > >> > > Now if #2 is chosen to be feasible and
> >> > acceptable
> >> > >> > then there are
> >> > >> > > >> > > a number of ways to actually do that. I
> >> > won't bring
> >> > >> > those up
> >> > >> > > >> > > until a clear decision is made on which
> >> > strategy
> >> > >> > above is the most acceptable.
> >> > >> > > >> > >
> >> > >> > > >> > Thanks for sending this out Brandon. I'm
> >> > in favor of
> >> > >> > option #2
> >> > >> > > >> > above, especially considering the
> >> > long-term plans to
> >> > >> > remove LBaaS
> >> > >> > > >> > from Neutron. That approach will help the
> >> > eventual end
> >> > >> > goal there.
> >> > >> > > >> > I am also curious on what others think,
> >> > and to this
> >> > >> > end, I've added
> >> > >> > > >> > this as an agenda item for the team
> >> > meeting next
> >> > >> > Monday. Brandon,
> >> > >> > > >> > it would be great to get you there for the
> >> > part of the
> >> > >> > meeting
> >> > >> > > >> > where we'll discuss this.
> >> > >> > > >> >
> >> > >> > > >> > Thanks!
> >> > >> > > >> > Kyle
> >> > >> > > >> >
> >> > >> > > >> > > Thanks,
> >> > >> > > >> > > Brandon
> >> > >> > > >> > >
> >> > >> > > >> > >
> >> > >> > > >> > >
> >> > >> > > >> > >
> >> > >> > > >> > >
> >> > >> > > >> > >
> >> > >> > > >> > >
> >> > _______________________________________________
> >> > >> > > >> > > 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
> >> > >
> >> >
> >> > _______________________________________________
> >> > OpenStack-dev mailing list
> >> > OpenStack-dev at lists.openstack.org
> >> >
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > OpenStack-dev mailing list
> >> > OpenStack-dev at lists.openstack.org
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140616/389513a6/attachment.html>
More information about the OpenStack-dev
mailing list