In the enStratus API, I return the count in the headers for a HEAD request. People seem to like that.
Sent from my iPhone On Nov 6, 2012, at 7:29, Nitin Mehta <nitin.me...@citrix.com> wrote: > > > On 06-Nov-2012, at 3:09 PM, Vijaykumar Natarajan wrote: > >> Isn't listAccounts available to an admin only? > > Its available for all. Let me know if it doesn't fit your case. > >> ----- Original Message ----- >> From: Nitin Mehta [mailto:nitin.me...@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.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 >
