Re: [openstack-dev] [Neutron][LBaaS] Consolidated metrics proposal
Hi Jorge, thanks for your reply! You are right about summarizing too much. The idea is to identify which kinds of data could be retrieved in a summarized way without losing detail (i.e.: uptime can be better described with start-end timestamps than with lots of samples with up/down status) or simply to provide different levels of granularity and let the user decide (yes, it can be sometimes dangerous). Having said this, how could we share the current metrics intended to be exposed? Is there a document or should I follow the "Requirements around statistics and billing" thread? Thank you! Andres From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] Sent: Thursday, June 12, 2014 6:35 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Consolidated metrics proposal Hey Andres, In my experience with usage gathering consolidating statistics at the root layer is usually a bad idea. The reason is that you lose potentially useful information once you consolidate data. When it comes to troubleshooting issues (such as billing) this lost information can cause problems since there is no way to "replay" what had actually happened. That said, there is no free lunch and keeping track of huge amounts of data can be a huge engineering challenge. We have a separate thread on what kinds of metrics we want to expose from the LBaaS service so perhaps it would be nice to understand these in more detail. Cheers, --Jorge From: , Andres mailto:andres.buras...@intel.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Tuesday, June 10, 2014 3:34 PM To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Subject: [openstack-dev] [Neutron][LBaaS] Consolidated metrics proposal Hi, we have been struggling with getting a meaningful set of metrics from LB stats thru ceilometer, and from a discussion about module responsibilities for providing data, an interesting idea came up. (Thanks Pradeep!) The proposal is to consolidate some kinds of metrics as pool up time (hours) and average or historic response times of VIPs and listeners, to avoid having ceilometer querying for the state so frequently. There is a trade-off between fast response time (high sampling rate) and reasonable* amount of cumulative samples. The next step in order to give more detail to the idea is to work on a use cases list to better explain / understand the benefits of this kind of data grouping. What dou you think about this? Do you find it will be useful to have some processed metrics on the loadbalancer side instead of the ceilometer side? Do you identify any measurements about the load balancer that could not be obtained/calculated from ceilometer? Perhaps this could be the base for other stats gathering solutions that may be under discussion? Andres ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][LBaaS] Consolidated metrics proposal
Hi, we have been struggling with getting a meaningful set of metrics from LB stats thru ceilometer, and from a discussion about module responsibilities for providing data, an interesting idea came up. (Thanks Pradeep!) The proposal is to consolidate some kinds of metrics as pool up time (hours) and average or historic response times of VIPs and listeners, to avoid having ceilometer querying for the state so frequently. There is a trade-off between fast response time (high sampling rate) and reasonable* amount of cumulative samples. The next step in order to give more detail to the idea is to work on a use cases list to better explain / understand the benefits of this kind of data grouping. What dou you think about this? Do you find it will be useful to have some processed metrics on the loadbalancer side instead of the ceilometer side? Do you identify any measurements about the load balancer that could not be obtained/calculated from ceilometer? Perhaps this could be the base for other stats gathering solutions that may be under discussion? Andres ___ 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, 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 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 >> > 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: >> > > -S
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 +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.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 > > 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
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 > 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
