[openstack-dev] [Neutron] Implementing new LBaaS API
Eugene Nikanorov
enikanorov at mirantis.com
Mon Jun 16 07:27:36 UTC 2014
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.
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140616/37adee29/attachment.html>
More information about the OpenStack-dev
mailing list