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: dev@cloudstack.apache.org <dev@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 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK @shapeblue