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>;
us...@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>;
us...@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.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> >
> > >
> > >
> >
>
daan.hoogl...@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
