Jessica, seems to broken when response is json; works for xml though: XML:
http://localhost:8096/?command=listConfigurations&pageSize=0&page=1 <listconfigurationsresponse cloud-stack-version="3.0.6.2012-11-06T00:49:55Z"> <count>266</count> </listconfigurationsresponse> JSON: http://localhost:8096/?command=listConfigurations&pageSize=0&page=1&respons e=json { "listconfigurationsresponse" : { } } -Alena. On 11/5/12 4:21 PM, "Jessica Wang" <jessica.w...@citrix.com> wrote: >http://localhost:8080/client/api?command=listVirtualMachines&response=json >&sessionkey=U%2Fu1EoHfSDXWu0o9boFvmBCoY%2Bc%3D&listAll=true&page=1&pagesiz >e=0&_=1352161157965 >{ "listvirtualmachinesresponse" : { } } > > >http://localhost:8080/client/api?command=listVirtualMachines&response=json >&sessionkey=U%2Fu1EoHfSDXWu0o9boFvmBCoY%2Bc%3D&listAll=true&page=1&pagesiz >e=1&_=1352161157965 >{ > "listvirtualmachinesresponse": { > "count": 3, > "virtualmachine": [ > { > "id": "64134e32-e2bb-4218-b41c-49e46c9bf6c0", > "name": "rootAdmin-VM1", > "displayname": "rootAdmin-VM1", > "account": "admin", > "domainid": "6f3f7ed7-4b79-4eb2-81d9-5ec59c17ed29", > "domain": "ROOT", > "created": "2012-10-30T10:44:56-0700", > "state": "Running", > "haenable": false, > "zoneid": "eeab8e27-5009-4a91-863b-505a0ef3ebcf", > "zonename": "jw-adv", > "hostid": "d7484af2-941e-417f-82c1-4cc29ff1c7d8", > "hostname": "xs-jessica", > "templateid": "ea22fcd7-d0a0-4c55-b85c-2b6404f1236d", > "templatename": "CentOS 5.6(64-bit) no GUI (XenServer)", > "templatedisplaytext": "CentOS 5.6(64-bit) no GUI >(XenServer)", > "passwordenabled": false, > "serviceofferingid": >"49e8c643-4598-4fb0-a7b7-a9a5b4a25ede", > "serviceofferingname": "Small Instance", > "cpunumber": 1, > "cpuspeed": 500, > "memory": 512, > "cpuused": "0.13%", > "networkkbsread": 24, > "networkkbswrite": 6, > "guestosid": "f50279e1-035b-4e5f-af5f-23bbed2220d2", > "rootdeviceid": 0, > "rootdevicetype": "NetworkFilesystem", > "securitygroup": [], > "nic": [ > { > "id": "43441330-db99-4444-8d9f-0519999de283", > "networkid": >"725dc10e-4a8d-414e-94e5-9b3022050a27", > "netmask": "255.255.255.0", > "gateway": "10.1.1.1", > "ipaddress": "10.1.1.187", > "isolationuri": "vlan://1028", > "broadcasturi": "vlan://1028", > "traffictype": "Guest", > "type": "Isolated", > "isdefault": true, > "macaddress": "02:00:7b:32:00:01" > } > ], > "hypervisor": "XenServer", > "publicipid": "22c945f5-da47-42d8-bb40-2184369227d9", > "publicip": "10.223.67.8", > "instancename": "i-2-3-TEST", > "tags": [] > } > ] > } >} > > > >-----Original Message----- >From: Jessica Wang [mailto:jessica.w...@citrix.com] >Sent: Monday, November 05, 2012 4:18 PM >To: cloudstack-dev@incubator.apache.org; Chiradeep Vittal; Alena >Prokharchyk >Cc: Min Chen >Subject: RE: Should we have separate "Count" API? > >Alena, > >pagesize=0 doesn't work. >pagesize=0 doesn't return count property. > >UI currently uses pagesize=1 as a workaround. > >Jessica > >-----Original Message----- >From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com] >Sent: Monday, November 05, 2012 4:16 PM >To: Chiradeep Vittal; CloudStack DeveloperList >Subject: Re: Should we have separate "Count" API? > >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.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.apa >>>c >>>h >>>e.org>" >>><cloudstack-dev@incubator.apache.org<mailto:cloudstack-...@incubator.apa >>>c >>>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.apa >>>c >>>h >>>e.org>" >>><cloudstack-dev@incubator.apache.org<mailto:cloudstack-...@incubator.apa >>>c >>>h >>>e.org>> >>>To: >>>"cloudstack-dev@incubator.apache.org<mailto:cloudstack-...@incubator.apa >>>c >>>h >>>e.org>" >>><cloudstack-dev@incubator.apache.org<mailto:cloudstack-...@incubator.apa >>>c >>>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 >>> >> >> > > >
