@Abhishek Kumar<mailto:abhishek.ku...@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 <david.jum...@shapeblue.com> Sent: Monday, April 5, 2021 09:08 To: d...@cloudstack.apache.org <d...@cloudstack.apache.org>; users@cloudstack.apache.org <users@cloudstack.apache.org> Subject: Re: Overprovisioning consideration in metrics API response +1 on this. Allocated should consider overprovisioning! ________________________________ From: Rohit Yadav <rohit.ya...@shapeblue.com> Sent: Wednesday, March 31, 2021 3:30 PM To: d...@cloudstack.apache.org <d...@cloudstack.apache.org>; users@cloudstack.apache.org <users@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 <abhishek.ku...@shapeblue.com> Sent: Wednesday, March 31, 2021 13:31 To: d...@cloudstack.apache.org <d...@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.ku...@shapeblue.com www.shapeblue.com<http://www.shapeblue.com> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK @shapeblue rohit.ya...@shapeblue.com www.shapeblue.com<http://www.shapeblue.com> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK @shapeblue david.jum...@shapeblue.com www.shapeblue.com<http://www.shapeblue.com> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK @shapeblue rohit.ya...@shapeblue.com www.shapeblue.com 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK @shapeblue
