On 11/7/12 9:52 AM, "Alex Huang" <alex.hu...@citrix.com> wrote:
>- CountOnly should have it's own API. Putting it as a parameter to the >call and have it completely change the semantics of the response doesn't >make sense to me. Alex, if we add new API, how do we request count for different CS objects based on the objects parameters? Lets say I want to count VirtualMachines, but only Vms in Running state created from the service offering id=5; or I want to count Snapshots having size > 1Mb. And how to build these 2 requests using the same API? >- If we return a count with the list, I agree with what George suggested. > The count should actually be in the header. It's more meta information. > Now, having a parameter that says turn off the count or turn on the >count in addition to the list makes sense. > >--Alex > >-----Original Message----- >From: Rohit Yadav [mailto:rohit.ya...@citrix.com] >Sent: Tuesday, November 06, 2012 9:25 PM >To: cloudstack-dev@incubator.apache.org >Subject: Re: Should we have separate "Count" API? > >countOnly would be better. If the only use of calling the API in that way >is to get the count, we may not want the clients (UI and CLI) to go >through the extra/overhead parsing and processing of the returned list of >objects. > >Thanks. > >Regards. > >On 06-Nov-2012, at 6:08 PM, Nitin Mehta <nitin.me...@citrix.com> wrote: > >> >> >> +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-dev@incubato >>>>> r.apac >>>>> h >>>>> e.org>" >>>>> <cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubato >>>>> r.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-dev@incubato >>>>> r.apac >>>>> h >>>>> e.org>" >>>>> <cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubato >>>>> r.apac >>>>> h >>>>> e.org>> >>>>> To: >>>>> "cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubato >>>>> r.apac >>>>> h >>>>> e.org>" >>>>> <cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubato >>>>> r.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 >>>>> >>>> >>> >> > >
