+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.vit...@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.c...@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.prokharc...@citrix.com<mailto:alena.prokharc...@citrix.com>> >>> Date: Monday, November 5, 2012 3:43 PM >>> To: >>> "cloudstack-dev@incubator.apache.org<mailto:cloudstack-...@incubator.apac >>> h >>> e.org>" >>> <cloudstack-dev@incubator.apache.org<mailto:cloudstack-...@incubator.apac >>> h >>> e.org>>, Min Chen <min.c...@citrix.com<mailto:min.c...@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.c...@citrix.com<mailto:min.c...@citrix.com>> >>> Reply-To: >>> "cloudstack-dev@incubator.apache.org<mailto:cloudstack-...@incubator.apac >>> h >>> e.org>" >>> <cloudstack-dev@incubator.apache.org<mailto:cloudstack-...@incubator.apac >>> h >>> e.org>> >>> To: >>> "cloudstack-dev@incubator.apache.org<mailto:cloudstack-...@incubator.apac >>> h >>> e.org>" >>> <cloudstack-dev@incubator.apache.org<mailto:cloudstack-...@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 >>> >> >
