incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alena Prokharchyk <Alena.Prokharc...@citrix.com>
Subject Re: Should we have separate "Count" API?
Date Tue, 06 Nov 2012 00:15:45 GMT
Good idea. 

As a workaround for now, you can call
listVms&page=1&pageSize=0&state=Running.

Zero objects will be returned, but "count" will be present in the response
showing how many running vms you have.

-Alena.

On 11/5/12 4:12 PM, "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