Re: [openstack-dev] [Neutron] Implementing new LBaaS API
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.lo...@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 +, Buraschi, Andres wrote: Thanks, Kyle. Great. -Original Message- From: Kyle Mestery [mailto:mest...@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.lo...@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 +, 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.lo...@rackspace.com] Sent: Wednesday, June 04, 2014 2:18 PM To: openstack-dev@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.lo...@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
Re: [openstack-dev] [Neutron] Implementing new LBaaS API
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? 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) 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 On 11 June 2014 18:01, Kyle Mestery mest...@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 sleipnir...@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.lo...@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.lo...@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 +, Buraschi, Andres wrote: Thanks, Kyle. Great. -Original Message- From: Kyle Mestery [mailto:mest...@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.lo...@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 +, 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
Re: [openstack-dev] [Neutron] Implementing new LBaaS API
. -Original Message- From: Kyle Mestery [mailto:mest...@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.lo...@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 +, 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.lo...@rackspace.com] Sent: Wednesday, June 04, 2014 2:18 PM To: openstack-dev@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.lo...@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
Re: [openstack-dev] [Neutron] Implementing new LBaaS API
Any core neutron people have a chance to give their opinions on this yet? Thanks, Brandon On Thu, 2014-06-05 at 15:28 +, Buraschi, Andres wrote: Thanks, Kyle. Great. -Original Message- From: Kyle Mestery [mailto:mest...@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.lo...@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 +, 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.lo...@rackspace.com] Sent: Wednesday, June 04, 2014 2:18 PM To: openstack-dev@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.lo...@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
Re: [openstack-dev] [Neutron] Implementing new LBaaS API
What was discussed at yesterday's Neutron core meeting? On Tue, Jun 10, 2014 at 3:38 PM, Brandon Logan brandon.lo...@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 +, Buraschi, Andres wrote: Thanks, Kyle. Great. -Original Message- From: Kyle Mestery [mailto:mest...@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.lo...@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 +, 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.lo...@rackspace.com] Sent: Wednesday, June 04, 2014 2:18 PM To: openstack-dev@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.lo...@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
Re: [openstack-dev] [Neutron] Implementing new LBaaS API
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.lo...@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 +, Buraschi, Andres wrote: Thanks, Kyle. Great. -Original Message- From: Kyle Mestery [mailto:mest...@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.lo...@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 +, 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.lo...@rackspace.com] Sent: Wednesday, June 04, 2014 2:18 PM To: openstack-dev@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.lo...@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
Re: [openstack-dev] [Neutron] Implementing new LBaaS API
Hi Brandon, thanks for your reply. Your explanation makes total sense to me. So, let's see what the consensus is. :) Regards and have a nice day! Andres -Original Message- From: Brandon Logan [mailto:brandon.lo...@rackspace.com] Sent: Wednesday, June 04, 2014 6:28 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Implementing new LBaaS API 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. Thanks, Brandon On Wed, 2014-06-04 at 20:30 +, 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.lo...@rackspace.com] Sent: Wednesday, June 04, 2014 2:18 PM To: openstack-dev@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.lo...@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
Re: [openstack-dev] [Neutron] Implementing new LBaaS API
On Wed, Jun 4, 2014 at 4:27 PM, Brandon Logan brandon.lo...@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 +, 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.lo...@rackspace.com] Sent: Wednesday, June 04, 2014 2:18 PM To: openstack-dev@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.lo...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http
Re: [openstack-dev] [Neutron] Implementing new LBaaS API
Thanks, Kyle. Great. -Original Message- From: Kyle Mestery [mailto:mest...@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.lo...@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 +, 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.lo...@rackspace.com] Sent: Wednesday, June 04, 2014 2:18 PM To: openstack-dev@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.lo...@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
Re: [openstack-dev] [Neutron] Implementing new LBaaS API
On Tue, Jun 3, 2014 at 3:01 PM, Brandon Logan brandon.lo...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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.lo...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Implementing new LBaaS API
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.lo...@rackspace.com] Sent: Wednesday, June 04, 2014 2:18 PM To: openstack-dev@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.lo...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Implementing new LBaaS API
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. Thanks, Brandon On Wed, 2014-06-04 at 20:30 +, 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.lo...@rackspace.com] Sent: Wednesday, June 04, 2014 2:18 PM To: openstack-dev@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.lo...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list
