<div dir="ltr">Do we know who has an opinion? If so maybe we can reach out to them directly and ask them to comment.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 10, 2014 at 6:44 PM, Brandon Logan <span dir="ltr"><<a href="mailto:brandon.logan@rackspace.com" target="_blank">brandon.logan@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Well we got a few opinions, but not enough understanding of the two<br>
options to make an informed decision. It was requested that the core<br>
reviewers respond to this thread with their opinions.<br>
<br>
Thanks,<br>
Brandon<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, 2014-06-10 at 13:22 -0700, Stephen Balukoff wrote:<br>
> Yep, I'd like to know here, too-- as knowing the answer to this<br>
> unblocks implementation work for us.<br>
><br>
><br>
> On Tue, Jun 10, 2014 at 12:38 PM, Brandon Logan<br>
> <<a href="mailto:brandon.logan@rackspace.com">brandon.logan@rackspace.com</a>> wrote:<br>
> Any core neutron people have a chance to give their opinions<br>
> on this<br>
> yet?<br>
><br>
> Thanks,<br>
> Brandon<br>
><br>
> On Thu, 2014-06-05 at 15:28 +0000, Buraschi, Andres wrote:<br>
> > Thanks, Kyle. Great.<br>
> ><br>
> > -----Original Message-----<br>
> > From: Kyle Mestery [mailto:<a href="mailto:mestery@noironetworks.com">mestery@noironetworks.com</a>]<br>
> > Sent: Thursday, June 05, 2014 11:27 AM<br>
> > To: OpenStack Development Mailing List (not for usage<br>
> questions)<br>
> > Subject: Re: [openstack-dev] [Neutron] Implementing new<br>
> LBaaS API<br>
> ><br>
> > On Wed, Jun 4, 2014 at 4:27 PM, Brandon Logan<br>
> <<a href="mailto:brandon.logan@rackspace.com">brandon.logan@rackspace.com</a>> wrote:<br>
> > > Hi Andres,<br>
> > > I've assumed (and we know how assumptions work) that the<br>
> deprecation<br>
> > > would take place in Juno and after a cyle or two it would<br>
> totally be<br>
> > > removed from the code. Even if #1 is the way to go, the<br>
> old /vips<br>
> > > resource would be deprecated in favor of /loadbalancers<br>
> and /listeners.<br>
> > ><br>
> > > I agree #2 is cleaner, but I don't want to start on an<br>
> implementation<br>
> > > (though I kind of already have) that will fail to be<br>
> merged in because<br>
> > > of the strategy. The strategies are pretty different so<br>
> one needs to<br>
> > > be decided on.<br>
> > ><br>
> > > As for where LBaaS is intended to end up, I don't want to<br>
> speak for<br>
> > > Kyle, so this is my understanding; It will end up outside<br>
> of the<br>
> > > Neutron code base but Neutron and LBaaS and other services<br>
> will all<br>
> > > fall under a Networking (or Network) program. That is my<br>
> > > understanding and I could be totally wrong.<br>
> > ><br>
> > That's my understanding as well, I think Brandon worded it<br>
> perfectly.<br>
> ><br>
> > > Thanks,<br>
> > > Brandon<br>
> > ><br>
> > > On Wed, 2014-06-04 at 20:30 +0000, Buraschi, Andres wrote:<br>
> > >> Hi Brandon, hi Kyle!<br>
> > >> I'm a bit confused about the deprecation (btw, thanks for<br>
> sending this Brandon!), as I (wrongly) assumed #1 would be the<br>
> chosen path for the new API implementation. I understand the<br>
> proposal and #2 sounds actually cleaner.<br>
> > >><br>
> > >> Just out of curiosity, Kyle, where is LBaaS functionality<br>
> intended to end up, if long-term plans are to remove it from<br>
> Neutron?<br>
> > >><br>
> > >> (Nit question, I must clarify)<br>
> > >><br>
> > >> Thank you!<br>
> > >> Andres<br>
> > >><br>
> > >> -----Original Message-----<br>
> > >> From: Brandon Logan [mailto:<a href="mailto:brandon.logan@RACKSPACE.COM">brandon.logan@RACKSPACE.COM</a>]<br>
> > >> Sent: Wednesday, June 04, 2014 2:18 PM<br>
> > >> To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
> > >> Subject: Re: [openstack-dev] [Neutron] Implementing new<br>
> LBaaS API<br>
> > >><br>
> > >> Thanks for your feedback Kyle. I will be at that meeting<br>
> on Monday.<br>
> > >><br>
> > >> Thanks,<br>
> > >> Brandon<br>
> > >><br>
> > >> On Wed, 2014-06-04 at 11:54 -0500, Kyle Mestery wrote:<br>
> > >> > On Tue, Jun 3, 2014 at 3:01 PM, Brandon Logan<br>
> > >> > <<a href="mailto:brandon.logan@rackspace.com">brandon.logan@rackspace.com</a>> wrote:<br>
> > >> > > This is an LBaaS topic bud I'd like to get some<br>
> Neutron Core<br>
> > >> > > members to give their opinions on this matter so I've<br>
> just<br>
> > >> > > directed this to Neutron proper.<br>
> > >> > ><br>
> > >> > > The design for the new API and object model for LBaaS<br>
> needs to be<br>
> > >> > > locked down before the hackathon in a couple of weeks<br>
> and there<br>
> > >> > > are some questions that need answered. This is<br>
> pretty urgent to<br>
> > >> > > come on to a decision on and to get a clear strategy<br>
> defined so<br>
> > >> > > we can actually do real code during the hackathon<br>
> instead of<br>
> > >> > > wasting some of that valuable time discussing this.<br>
> > >> > ><br>
> > >> > ><br>
> > >> > > Implementation must be backwards compatible<br>
> > >> > ><br>
> > >> > > There are 2 ways that have come up on how to do this:<br>
> > >> > ><br>
> > >> > > 1) New API and object model are created in the same<br>
> extension and<br>
> > >> > > plugin as the old. Any API requests structured for<br>
> the old API<br>
> > >> > > will be translated/adapted to the into the new object<br>
> model.<br>
> > >> > > PROS:<br>
> > >> > > -Only one extension and plugin<br>
> > >> > > -Mostly true backwards compatibility -Do not have to<br>
> rename<br>
> > >> > > unchanged resources and models<br>
> > >> > > CONS:<br>
> > >> > > -May end up being confusing to an end-user.<br>
> > >> > > -Separation of old api and new api is less clear<br>
> -Deprecating and<br>
> > >> > > removing old api and object model will take a bit<br>
> more work -This<br>
> > >> > > is basically API versioning the wrong way<br>
> > >> > ><br>
> > >> > > 2) A new extension and plugin are created for the new<br>
> API and<br>
> > >> > > object model. Each API would live side by side. New<br>
> API would<br>
> > >> > > need to have different names for resources and object<br>
> models from<br>
> > >> > > Old API resources and object models.<br>
> > >> > > PROS:<br>
> > >> > > -Clean demarcation point between old and new -No<br>
> translation<br>
> > >> > > layer needed -Do not need to modify existing API and<br>
> object<br>
> > >> > > model, no new bugs -Drivers do not need to be<br>
> immediately<br>
> > >> > > modified -Easy to deprecate and remove old API and<br>
> object model<br>
> > >> > > later<br>
> > >> > > CONS:<br>
> > >> > > -Separate extensions and object model will be<br>
> confusing to<br>
> > >> > > end-users -Code reuse by copy paste since old<br>
> extension and<br>
> > >> > > plugin will be deprecated and removed.<br>
> > >> > > -This is basically API versioning the wrong way<br>
> > >> > ><br>
> > >> > > Now if #2 is chosen to be feasible and acceptable<br>
> then there are<br>
> > >> > > a number of ways to actually do that. I won't bring<br>
> those up<br>
> > >> > > until a clear decision is made on which strategy<br>
> above is the most acceptable.<br>
> > >> > ><br>
> > >> > Thanks for sending this out Brandon. I'm in favor of<br>
> option #2<br>
> > >> > above, especially considering the long-term plans to<br>
> remove LBaaS<br>
> > >> > from Neutron. That approach will help the eventual end<br>
> goal there.<br>
> > >> > I am also curious on what others think, and to this<br>
> end, I've added<br>
> > >> > this as an agenda item for the team meeting next<br>
> Monday. Brandon,<br>
> > >> > it would be great to get you there for the part of the<br>
> meeting<br>
> > >> > where we'll discuss this.<br>
> > >> ><br>
> > >> > Thanks!<br>
> > >> > Kyle<br>
> > >> ><br>
> > >> > > Thanks,<br>
> > >> > > Brandon<br>
> > >> > ><br>
> > >> > ><br>
> > >> > ><br>
> > >> > ><br>
> > >> > ><br>
> > >> > ><br>
> > >> > > _______________________________________________<br>
> > >> > > OpenStack-dev mailing list<br>
> > >> > > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > >> > ><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> > >> ><br>
> > >> > _______________________________________________<br>
> > >> > OpenStack-dev mailing list<br>
> > >> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > >> ><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> > >><br>
> > >> _______________________________________________<br>
> > >> OpenStack-dev mailing list<br>
> > >> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > >><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> > >><br>
> > >> _______________________________________________<br>
> > >> OpenStack-dev mailing list<br>
> > >> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > >><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> > ><br>
> > > _______________________________________________<br>
> > > OpenStack-dev mailing list<br>
> > > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > ><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> ><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> ><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
><br>
><br>
> --<br>
> Stephen Balukoff<br>
> Blue Box Group, LLC<br>
> <a href="tel:%28800%29613-4305%20x807" value="+18006134305">(800)613-4305 x807</a><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>