You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by David Jumani <Da...@shapeblue.com> on 2021/04/05 03:38:14 UTC
Re: Overprovisioning consideration in metrics API response
+1 on this. Allocated should consider overprovisioning!
________________________________
From: Rohit Yadav <ro...@shapeblue.com>
Sent: Wednesday, March 31, 2021 3:30 PM
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>; users@cloudstack.apache.org <us...@cloudstack.apache.org>
Subject: Re: Overprovisioning consideration in metrics API response
Thanks for starting this thread Abhishek. I think all 'allocated' API response keys (irrespective of type such as CPU, RAM, storage/disk etc) across all list/metrics APIs should consider overprovisioning factor.
For example, if the total resource value/limit is 100 and overprovisioning factor is 1.5 that means CloudStack can effectively allocate 1.5*100=150 of that resource, which in actual or physical value is (allocated value / over-provisioning factor). Let me add user@ ML to hear if users agree with my interpretation of allocated values/metrics.
Regards.
________________________________
From: Abhishek Kumar <Ab...@shapeblue.com>
Sent: Wednesday, March 31, 2021 13:31
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Subject: Overprovisioning consideration in metrics API response
Hi devs,
There have been recurring issues and changes for API responses not considering the over-provisioning factor while reporting metrics for hosts, clusters, etc.
https://github.com/apache/cloudstack/issues/4778
https://github.com/apache/cloudstack/pull/4850
https://github.com/apache/cloudstack/pull/4499
While some of the metric parameters doesn't consider overprovisioning at all, some give value in the format- "memorytotalgb": "6.78 GB (x 1.0)".
So, to address this should we consider a code/API-wide change?
And while fixing it should we introduce new parameters such as - cputotalwithoverprovisioning, memorytotalwithoverprovisioning, etc or should we apply the overprovisioning factors to the existing response parameters?
Please share your thoughts.
Regards,
Abhishek
Abhishek.Kumar@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
rohit.yadav@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
David.Jumani@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
Re: Overprovisioning consideration in metrics API response
Posted by Daan Hoogland <da...@shapeblue.com>.
Abhishek (and others),
I don't think we should make any changes to output parameters unless
they do explicitly not what they describe. It make sense to add
parameters with more explicit names/description. I can not read from
this thread if that is the consensus, so I just add my view to the
after-party.
On 2021/04/05 07:33:41, Rohit Yadav <r....@shapeblue.com> wrote:
> @Abhishek Kumar<ma...@shapeblue.com> - let's wait at least the end of
this week if we receive any objections, otherwise go ahead with your
proposal to fix the allocated values as part of the API responses.> >
> >
> >
> Regards.> >
> >
> ________________________________> >
> From: David Jumani <Da...@shapeblue.com>> >
> Sent: Monday, April 5, 2021 09:08> >
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>;
users@cloudstack.apache.org <us...@cloudstack.apache.org>> >
> Subject: Re: Overprovisioning consideration in metrics API response> >
> >
> +1 on this. Allocated should consider overprovisioning!> >
> ________________________________> >
> From: Rohit Yadav <ro...@shapeblue.com>> >
> Sent: Wednesday, March 31, 2021 3:30 PM> >
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>;
users@cloudstack.apache.org <us...@cloudstack.apache.org>> >
> Subject: Re: Overprovisioning consideration in metrics API response> >
> >
> Thanks for starting this thread Abhishek. I think all 'allocated' API
response keys (irrespective of type such as CPU, RAM, storage/disk etc)
across all list/metrics APIs should consider overprovisioning factor.> >
> >
> For example, if the total resource value/limit is 100 and
overprovisioning factor is 1.5 that means CloudStack can effectively
allocate 1.5*100=150 of that resource, which in actual or physical value
is (allocated value / over-provisioning factor). Let me add user@ ML to
hear if users agree with my interpretation of allocated values/metrics.> >
> >
> >
> Regards.> >
> >
> ________________________________> >
> From: Abhishek Kumar <Ab...@shapeblue.com>> >
> Sent: Wednesday, March 31, 2021 13:31> >
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>> >
> Subject: Overprovisioning consideration in metrics API response> >
> >
> Hi devs,> >
> >
> There have been recurring issues and changes for API responses not
considering the over-provisioning factor while reporting metrics for
hosts, clusters, etc.> >
> https://github.com/apache/cloudstack/issues/4778> >
> https://github.com/apache/cloudstack/pull/4850> >
> https://github.com/apache/cloudstack/pull/4499> >
> >
> While some of the metric parameters doesn't consider overprovisioning
at all, some give value in the format- "memorytotalgb": "6.78 GB (x
1.0)".> >
> So, to address this should we consider a code/API-wide change?> >
> And while fixing it should we introduce new parameters such as -
cputotalwithoverprovisioning, memorytotalwithoverprovisioning, etc or
should we apply the overprovisioning factors to the existing response
parameters?> >
> Please share your thoughts.> >
> >
> Regards,> >
> Abhishek> >
> >
> Abhishek.Kumar@shapeblue.com> >
> www.shapeblue.com<http://www.shapeblue.com>> >
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK> >
> @shapeblue> >
> >
> >
> >
> >
> rohit.yadav@shapeblue.com> >
> www.shapeblue.com<http://www.shapeblue.com>> >
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK> >
> @shapeblue> >
> >
> >
> >
> >
> David.Jumani@shapeblue.com> >
> www.shapeblue.com<http://www.shapeblue.com>> >
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK> >
> @shapeblue> >
> >
> >
> >
> >
> rohit.yadav@shapeblue.com > >
> www.shapeblue.com> >
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK> >
> @shapeblue> >
> > >
> > >
> >
>
daan.hoogland@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
Re: Overprovisioning consideration in metrics API response
Posted by Rohit Yadav <ro...@shapeblue.com>.
@Abhishek Kumar<ma...@shapeblue.com> - let's wait at least the end of this week if we receive any objections, otherwise go ahead with your proposal to fix the allocated values as part of the API responses.
Regards.
________________________________
From: David Jumani <Da...@shapeblue.com>
Sent: Monday, April 5, 2021 09:08
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>; users@cloudstack.apache.org <us...@cloudstack.apache.org>
Subject: Re: Overprovisioning consideration in metrics API response
+1 on this. Allocated should consider overprovisioning!
________________________________
From: Rohit Yadav <ro...@shapeblue.com>
Sent: Wednesday, March 31, 2021 3:30 PM
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>; users@cloudstack.apache.org <us...@cloudstack.apache.org>
Subject: Re: Overprovisioning consideration in metrics API response
Thanks for starting this thread Abhishek. I think all 'allocated' API response keys (irrespective of type such as CPU, RAM, storage/disk etc) across all list/metrics APIs should consider overprovisioning factor.
For example, if the total resource value/limit is 100 and overprovisioning factor is 1.5 that means CloudStack can effectively allocate 1.5*100=150 of that resource, which in actual or physical value is (allocated value / over-provisioning factor). Let me add user@ ML to hear if users agree with my interpretation of allocated values/metrics.
Regards.
________________________________
From: Abhishek Kumar <Ab...@shapeblue.com>
Sent: Wednesday, March 31, 2021 13:31
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Subject: Overprovisioning consideration in metrics API response
Hi devs,
There have been recurring issues and changes for API responses not considering the over-provisioning factor while reporting metrics for hosts, clusters, etc.
https://github.com/apache/cloudstack/issues/4778
https://github.com/apache/cloudstack/pull/4850
https://github.com/apache/cloudstack/pull/4499
While some of the metric parameters doesn't consider overprovisioning at all, some give value in the format- "memorytotalgb": "6.78 GB (x 1.0)".
So, to address this should we consider a code/API-wide change?
And while fixing it should we introduce new parameters such as - cputotalwithoverprovisioning, memorytotalwithoverprovisioning, etc or should we apply the overprovisioning factors to the existing response parameters?
Please share your thoughts.
Regards,
Abhishek
Abhishek.Kumar@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
rohit.yadav@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
David.Jumani@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
rohit.yadav@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
Re: Overprovisioning consideration in metrics API response
Posted by Rohit Yadav <ro...@shapeblue.com>.
@Abhishek Kumar<ma...@shapeblue.com> - let's wait at least the end of this week if we receive any objections, otherwise go ahead with your proposal to fix the allocated values as part of the API responses.
Regards.
________________________________
From: David Jumani <Da...@shapeblue.com>
Sent: Monday, April 5, 2021 09:08
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>; users@cloudstack.apache.org <us...@cloudstack.apache.org>
Subject: Re: Overprovisioning consideration in metrics API response
+1 on this. Allocated should consider overprovisioning!
________________________________
From: Rohit Yadav <ro...@shapeblue.com>
Sent: Wednesday, March 31, 2021 3:30 PM
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>; users@cloudstack.apache.org <us...@cloudstack.apache.org>
Subject: Re: Overprovisioning consideration in metrics API response
Thanks for starting this thread Abhishek. I think all 'allocated' API response keys (irrespective of type such as CPU, RAM, storage/disk etc) across all list/metrics APIs should consider overprovisioning factor.
For example, if the total resource value/limit is 100 and overprovisioning factor is 1.5 that means CloudStack can effectively allocate 1.5*100=150 of that resource, which in actual or physical value is (allocated value / over-provisioning factor). Let me add user@ ML to hear if users agree with my interpretation of allocated values/metrics.
Regards.
________________________________
From: Abhishek Kumar <Ab...@shapeblue.com>
Sent: Wednesday, March 31, 2021 13:31
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Subject: Overprovisioning consideration in metrics API response
Hi devs,
There have been recurring issues and changes for API responses not considering the over-provisioning factor while reporting metrics for hosts, clusters, etc.
https://github.com/apache/cloudstack/issues/4778
https://github.com/apache/cloudstack/pull/4850
https://github.com/apache/cloudstack/pull/4499
While some of the metric parameters doesn't consider overprovisioning at all, some give value in the format- "memorytotalgb": "6.78 GB (x 1.0)".
So, to address this should we consider a code/API-wide change?
And while fixing it should we introduce new parameters such as - cputotalwithoverprovisioning, memorytotalwithoverprovisioning, etc or should we apply the overprovisioning factors to the existing response parameters?
Please share your thoughts.
Regards,
Abhishek
Abhishek.Kumar@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
rohit.yadav@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
David.Jumani@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
rohit.yadav@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue