<div dir="ltr">What was discussed at yesterday's Neutron core meeting?<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 10, 2014 at 3:38 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">Any core neutron people have a chance to give their opinions on this<br>
yet?<br>
<br>
Thanks,<br>
Brandon<br>
<div class="HOEnZb"><div class="h5"><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 questions)<br>
> Subject: Re: [openstack-dev] [Neutron] Implementing new LBaaS API<br>
><br>
> On Wed, Jun 4, 2014 at 4:27 PM, Brandon Logan <<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 deprecation<br>
> > would take place in Juno and after a cyle or two it would totally be<br>
> > removed from the code. Even if #1 is the way to go, the old /vips<br>
> > resource would be deprecated in favor of /loadbalancers and /listeners.<br>
> ><br>
> > I agree #2 is cleaner, but I don't want to start on an implementation<br>
> > (though I kind of already have) that will fail to be merged in because<br>
> > of the strategy. The strategies are pretty different so one needs to<br>
> > be decided on.<br>
> ><br>
> > As for where LBaaS is intended to end up, I don't want to speak for<br>
> > Kyle, so this is my understanding; It will end up outside of the<br>
> > Neutron code base but Neutron and LBaaS and other services 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 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 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.<br>
> >><br>
> >> Just out of curiosity, Kyle, where is LBaaS functionality intended to end up, if long-term plans are to remove it from 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 LBaaS API<br>
> >><br>
> >> Thanks for your feedback Kyle. I will be at that meeting 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 Neutron Core<br>
> >> > > members to give their opinions on this matter so I've just<br>
> >> > > directed this to Neutron proper.<br>
> >> > ><br>
> >> > > The design for the new API and object model for LBaaS needs to be<br>
> >> > > locked down before the hackathon in a couple of weeks and there<br>
> >> > > are some questions that need answered. This is pretty urgent to<br>
> >> > > come on to a decision on and to get a clear strategy defined so<br>
> >> > > we can actually do real code during the hackathon 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 extension and<br>
> >> > > plugin as the old. Any API requests structured for the old API<br>
> >> > > will be translated/adapted to the into the new object model.<br>
> >> > > PROS:<br>
> >> > > -Only one extension and plugin<br>
> >> > > -Mostly true backwards compatibility -Do not have to 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 -Deprecating and<br>
> >> > > removing old api and object model will take a bit more work -This<br>
> >> > > is basically API versioning the wrong way<br>
> >> > ><br>
> >> > > 2) A new extension and plugin are created for the new API and<br>
> >> > > object model. Each API would live side by side. New API would<br>
> >> > > need to have different names for resources and object models from<br>
> >> > > Old API resources and object models.<br>
> >> > > PROS:<br>
> >> > > -Clean demarcation point between old and new -No translation<br>
> >> > > layer needed -Do not need to modify existing API and object<br>
> >> > > model, no new bugs -Drivers do not need to be immediately<br>
> >> > > modified -Easy to deprecate and remove old API and object model<br>
> >> > > later<br>
> >> > > CONS:<br>
> >> > > -Separate extensions and object model will be confusing to<br>
> >> > > end-users -Code reuse by copy paste since old 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 then there are<br>
> >> > > a number of ways to actually do that. I won't bring those up<br>
> >> > > until a clear decision is made on which strategy above is the most acceptable.<br>
> >> > ><br>
> >> > Thanks for sending this out Brandon. I'm in favor of option #2<br>
> >> > above, especially considering the long-term plans to remove LBaaS<br>
> >> > from Neutron. That approach will help the eventual end goal there.<br>
> >> > I am also curious on what others think, and to this end, I've added<br>
> >> > this as an agenda item for the team meeting next Monday. Brandon,<br>
> >> > it would be great to get you there for the part of the 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>
> >> > > <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>
> >> 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>
> ><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>
><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>