incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vijaykumar Natarajan <vijay.natara...@citrix.com>
Subject Re: Should we have separate "Count" API?
Date Tue, 06 Nov 2012 13:09:01 GMT
Isn't listAccounts available to an admin only?

----- Original Message -----
From: Nitin Mehta [mailto:Nitin.Mehta@citrix.com]
Sent: Tuesday, November 06, 2012 06:08 PM
To: cloudstack-dev@incubator.apache.org <cloudstack-dev@incubator.apache.org>
Subject: Re: Should we have separate "Count" API?



+1 to adding countOnly flag.


On 06-Nov-2012, at 7:02 AM, Vijaykumar Natarajan wrote:

> IMHO,
> 
> Instead of a count or countOnly API for each resource type, it'd be better
> to create a stats API which returns counts for all resources (no of vms,
> no of Ips etc.). This is typically the use case (in dashboards etc) for
> which the count is really useful and will avoid multiple calls to get all
> this information. Not averse to the suggestion below (which can always
> exist in addition to the stats API), though.
> 
> -- Cheers
> Vijay
> 


I think listAccounts already gives that info for vms, ips, volumes count etc. belonging to
that account.
Thats what the UI also uses to get the count info for a particular account.
 

> On 11/6/12 5:42 AM, "Chiradeep Vittal" <Chiradeep.Vittal@citrix.com> wrote:
> 
>> I like the "countOnly" idea. If it were a proper REST API, it would be
>> GET /vm/count?state=Running
>> And
>> GET /vm?state=Running
>> 
>> On 11/5/12 4:03 PM, "Min Chen" <min.chen@citrix.com> wrote:
>> 
>>> Thanks Alena. Maybe we should support a query parameter "countOnly" or
>>> something for count only case to avoid issuing extra sql queries.
>>> 
>>> -min
>>> 
>>> From: Alena Prokharchyk
>>> <Alena.Prokharchyk@citrix.com<mailto:Alena.Prokharchyk@citrix.com>>
>>> Date: Monday, November 5, 2012 3:43 PM
>>> To: 
>>> "cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apac
>>> h
>>> e.org>" 
>>> <cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apac
>>> h
>>> e.org>>, Min Chen <min.chen@citrix.com<mailto:min.chen@citrix.com>>
>>> Subject: Re: Should we have separate "Count" API?
>>> 
>>> Min,
>>> 
>>> We didn't use separate call as well as didn't use resource count table
>>> because we "count" field represents the number of DB resources matching
>>> the search criteria (ignoring page/pageSize info) specified in the list*
>>> api call. For example:
>>> 
>>> listVirtualMachines&state=Running&hostId=1&page=1&pageSize=1
>>> 
>>> In the "count" field we expect to see the only how many vms in Running
>>> state, running on hostId=1 exist in the system; not the entire number of
>>> vms  in the system that we keep per account in resource_count table.
>>> And although only one vm object will be returned (as you requested
>>> page=1&pageSize=1), you'll know how many vms in the system satisfy the
>>> search criteria.
>>> 
>>> As variation of parameters depends on particular API call, the count has
>>> to be returned as a part of list* command response.
>>> 
>>> -Alena.
>>> 
>>> From: Min Chen <min.chen@citrix.com<mailto:min.chen@citrix.com>>
>>> Reply-To: 
>>> "cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apac
>>> h
>>> e.org>" 
>>> <cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apac
>>> h
>>> e.org>>
>>> To: 
>>> "cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apac
>>> h
>>> e.org>" 
>>> <cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apac
>>> h
>>> e.org>>
>>> Subject: Should we have separate "Count" API?
>>> 
>>> Hi there,
>>> 
>>> In fixing the bug regarding count of a list API today, I cannot help
>>> wondering why we cannot have separate "Count" api for such purpose rather
>>> than bundling this information with list API, where we basically return
>>> some information that some users will just throw away since they only
>>> care about count for dashboard purpose. I also noticed that in our DB
>>> schema, we actually have a table "resource_count" there, not sure the
>>> original rational behind this table. If we can take advantage of this
>>> table (and keep the information there up-to-date), we may be able to
>>> provide a very efficient way to implement such "Count' apis for most
>>> commonly used cases.
>>> Any thoughts on this?
>>> 
>>> Thanks
>>> -min
>>> 
>> 
> 


Mime
View raw message