You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Min Chen <mi...@citrix.com> on 2012/11/06 00:29:18 UTC
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
Re: Should we have separate "Count" API?
Posted by John Burwell <jb...@basho.com>.
George,
+1 -- my response exactly. The HTTP protocol provides the semantic for this type of information through a HEAD operation.
Thanks,
-John
On Nov 5, 2012, at 7:02 PM, Jessica Wang <Je...@citrix.com> wrote:
> Edison,
>
> "count" is not referring to how many items in an API response.
> "count" is referring to how many items in database.
>
> e.g. There are 3500 VMs in database.
> listVirtualMachines API returns 500 VMs each time (by page parameter and pagesize parameter).
> In this case, "count" will be 3500 instead of 500.
>
> Jessica
>
> -----Original Message-----
> From: Edison Su [mailto:Edison.su@citrix.com]
> Sent: Monday, November 05, 2012 3:57 PM
> To: cloudstack-dev@incubator.apache.org; Min Chen
> Subject: RE: Should we have separate "Count" API?
>
> If we return a list in the list API, e.g. [VM1, VM2, .., VMn], the "count", or the length of list can be inferred from the list. When I write the python binding for cloudstack API, I found "count" field is not that usefull.
>
>> -----Original Message-----
>> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
>> Sent: Monday, November 05, 2012 3:44 PM
>> To: cloudstack-dev@incubator.apache.org; Min Chen
>> 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 <mi...@citrix.com>>
>> Reply-To: "cloudstack-dev@incubator.apache.org<mailto:cloudstack-
>> dev@incubator.apache.org>" <cloudstack-
>> dev@incubator.apache.org<ma...@incubator.apache.org>>
>> To: "cloudstack-dev@incubator.apache.org<mailto:cloudstack-
>> dev@incubator.apache.org>" <cloudstack-
>> dev@incubator.apache.org<ma...@incubator.apache.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
>
RE: Should we have separate "Count" API?
Posted by Jessica Wang <Je...@citrix.com>.
Edison,
"count" is not referring to how many items in an API response.
"count" is referring to how many items in database.
e.g. There are 3500 VMs in database.
listVirtualMachines API returns 500 VMs each time (by page parameter and pagesize parameter).
In this case, "count" will be 3500 instead of 500.
Jessica
-----Original Message-----
From: Edison Su [mailto:Edison.su@citrix.com]
Sent: Monday, November 05, 2012 3:57 PM
To: cloudstack-dev@incubator.apache.org; Min Chen
Subject: RE: Should we have separate "Count" API?
If we return a list in the list API, e.g. [VM1, VM2, .., VMn], the "count", or the length of list can be inferred from the list. When I write the python binding for cloudstack API, I found "count" field is not that usefull.
> -----Original Message-----
> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
> Sent: Monday, November 05, 2012 3:44 PM
> To: cloudstack-dev@incubator.apache.org; Min Chen
> 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 <mi...@citrix.com>>
> Reply-To: "cloudstack-dev@incubator.apache.org<mailto:cloudstack-
> dev@incubator.apache.org>" <cloudstack-
> dev@incubator.apache.org<ma...@incubator.apache.org>>
> To: "cloudstack-dev@incubator.apache.org<mailto:cloudstack-
> dev@incubator.apache.org>" <cloudstack-
> dev@incubator.apache.org<ma...@incubator.apache.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
Re: Should we have separate "Count" API?
Posted by Alena Prokharchyk <Al...@citrix.com>.
On 11/5/12 3:56 PM, "Edison Su" <Ed...@citrix.com> wrote:
>If we return a list in the list API, e.g. [VM1, VM2, .., VMn], the
>"count", or the length of list can be inferred from the list. When I
>write the python binding for cloudstack API, I found "count" field is not
>that usefull.
Edison, it was fixed recently. Now "count" represents how many items in
the DB match your search criteria; not the number of the items you
requested with page/pagesize.
-Alena.
>
>> -----Original Message-----
>> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
>> Sent: Monday, November 05, 2012 3:44 PM
>> To: cloudstack-dev@incubator.apache.org; Min Chen
>> 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 <mi...@citrix.com>>
>> Reply-To: "cloudstack-dev@incubator.apache.org<mailto:cloudstack-
>> dev@incubator.apache.org>" <cloudstack-
>> dev@incubator.apache.org<ma...@incubator.apache.org>>
>> To: "cloudstack-dev@incubator.apache.org<mailto:cloudstack-
>> dev@incubator.apache.org>" <cloudstack-
>> dev@incubator.apache.org<ma...@incubator.apache.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
>
>
Re: Should we have separate "Count" API?
Posted by Min Chen <mi...@citrix.com>.
When the pageSize and page are specified, "count" returned will be
different from the length of the list.
-min
On 11/5/12 3:56 PM, "Edison Su" <Ed...@citrix.com> wrote:
>If we return a list in the list API, e.g. [VM1, VM2, .., VMn], the
>"count", or the length of list can be inferred from the list. When I
>write the python binding for cloudstack API, I found "count" field is not
>that usefull.
>
>> -----Original Message-----
>> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
>> Sent: Monday, November 05, 2012 3:44 PM
>> To: cloudstack-dev@incubator.apache.org; Min Chen
>> 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 <mi...@citrix.com>>
>> Reply-To: "cloudstack-dev@incubator.apache.org<mailto:cloudstack-
>> dev@incubator.apache.org>" <cloudstack-
>> dev@incubator.apache.org<ma...@incubator.apache.org>>
>> To: "cloudstack-dev@incubator.apache.org<mailto:cloudstack-
>> dev@incubator.apache.org>" <cloudstack-
>> dev@incubator.apache.org<ma...@incubator.apache.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
>
RE: Should we have separate "Count" API?
Posted by Edison Su <Ed...@citrix.com>.
If we return a list in the list API, e.g. [VM1, VM2, .., VMn], the "count", or the length of list can be inferred from the list. When I write the python binding for cloudstack API, I found "count" field is not that usefull.
> -----Original Message-----
> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
> Sent: Monday, November 05, 2012 3:44 PM
> To: cloudstack-dev@incubator.apache.org; Min Chen
> 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 <mi...@citrix.com>>
> Reply-To: "cloudstack-dev@incubator.apache.org<mailto:cloudstack-
> dev@incubator.apache.org>" <cloudstack-
> dev@incubator.apache.org<ma...@incubator.apache.org>>
> To: "cloudstack-dev@incubator.apache.org<mailto:cloudstack-
> dev@incubator.apache.org>" <cloudstack-
> dev@incubator.apache.org<ma...@incubator.apache.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
RE: Should we have separate "Count" API?
Posted by Jessica Wang <Je...@citrix.com>.
There are a lot of places on UI that needs only count number of resources (e.g. VM count, volume count, zone count, pod count, cluster count, host count, primary storage count, etc).
However, API always return embedded objects as well even they are not needed.
Returning embedded objects slow down API response time.
-----Original Message-----
From: Jessica Wang
Sent: Monday, November 05, 2012 4:09 PM
To: cloudstack-dev@incubator.apache.org; Alena Prokharchyk
Cc: Min Chen
Subject: RE: Should we have separate "Count" API?
+1
-----Original Message-----
From: Min Chen [mailto:min.chen@citrix.com]
Sent: Monday, November 05, 2012 4:04 PM
To: Alena Prokharchyk; cloudstack-dev@incubator.apache.org
Subject: Re: Should we have separate "Count" API?
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 <Al...@citrix.com>>
Date: Monday, November 5, 2012 3:43 PM
To: "cloudstack-dev@incubator.apache.org<ma...@incubator.apache.org>" <cl...@incubator.apache.org>>, Min Chen <mi...@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 <mi...@citrix.com>>
Reply-To: "cloudstack-dev@incubator.apache.org<ma...@incubator.apache.org>" <cl...@incubator.apache.org>>
To: "cloudstack-dev@incubator.apache.org<ma...@incubator.apache.org>" <cl...@incubator.apache.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
RE: Should we have separate "Count" API?
Posted by Jessica Wang <Je...@citrix.com>.
+1
-----Original Message-----
From: Min Chen [mailto:min.chen@citrix.com]
Sent: Monday, November 05, 2012 4:04 PM
To: Alena Prokharchyk; cloudstack-dev@incubator.apache.org
Subject: Re: Should we have separate "Count" API?
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 <Al...@citrix.com>>
Date: Monday, November 5, 2012 3:43 PM
To: "cloudstack-dev@incubator.apache.org<ma...@incubator.apache.org>" <cl...@incubator.apache.org>>, Min Chen <mi...@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 <mi...@citrix.com>>
Reply-To: "cloudstack-dev@incubator.apache.org<ma...@incubator.apache.org>" <cl...@incubator.apache.org>>
To: "cloudstack-dev@incubator.apache.org<ma...@incubator.apache.org>" <cl...@incubator.apache.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
RE: Should we have separate "Count" API?
Posted by Jessica Wang <Je...@citrix.com>.
Thanks, Alena,
I just filed a bug for this.
-----Original Message-----
From: Alena Prokharchyk
Sent: Monday, November 05, 2012 4:54 PM
To: Jessica Wang; cloudstack-dev@incubator.apache.org; Chiradeep Vittal
Cc: Min Chen
Subject: Re: Should we have separate "Count" API?
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" <Je...@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.Wang@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.Prokharchyk@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" <Ch...@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" <mi...@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
>>><Al...@citrix.com>>
>>>Date: Monday, November 5, 2012 3:43 PM
>>>To:
>>>"cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apa
>>>c
>>>h
>>>e.org>"
>>><cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apa
>>>c
>>>h
>>>e.org>>, Min Chen <mi...@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 <mi...@citrix.com>>
>>>Reply-To:
>>>"cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apa
>>>c
>>>h
>>>e.org>"
>>><cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apa
>>>c
>>>h
>>>e.org>>
>>>To:
>>>"cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apa
>>>c
>>>h
>>>e.org>"
>>><cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@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
>>>
>>
>>
>
>
>
Re: Should we have separate "Count" API?
Posted by Alena Prokharchyk <Al...@citrix.com>.
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" <Je...@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.Wang@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.Prokharchyk@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" <Ch...@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" <mi...@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
>>><Al...@citrix.com>>
>>>Date: Monday, November 5, 2012 3:43 PM
>>>To:
>>>"cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apa
>>>c
>>>h
>>>e.org>"
>>><cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apa
>>>c
>>>h
>>>e.org>>, Min Chen <mi...@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 <mi...@citrix.com>>
>>>Reply-To:
>>>"cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apa
>>>c
>>>h
>>>e.org>"
>>><cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apa
>>>c
>>>h
>>>e.org>>
>>>To:
>>>"cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apa
>>>c
>>>h
>>>e.org>"
>>><cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@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
>>>
>>
>>
>
>
>
RE: Should we have separate "Count" API?
Posted by Jessica Wang <Je...@citrix.com>.
http://localhost:8080/client/api?command=listVirtualMachines&response=json&sessionkey=U%2Fu1EoHfSDXWu0o9boFvmBCoY%2Bc%3D&listAll=true&page=1&pagesize=0&_=1352161157965
{ "listvirtualmachinesresponse" : { } }
http://localhost:8080/client/api?command=listVirtualMachines&response=json&sessionkey=U%2Fu1EoHfSDXWu0o9boFvmBCoY%2Bc%3D&listAll=true&page=1&pagesize=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.Wang@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.Prokharchyk@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" <Ch...@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" <mi...@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
>><Al...@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 <mi...@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 <mi...@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
>>
>
>
RE: Should we have separate "Count" API?
Posted by Jessica Wang <Je...@citrix.com>.
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.Prokharchyk@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" <Ch...@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" <mi...@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
>><Al...@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 <mi...@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 <mi...@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
>>
>
>
RE: Should we have separate "Count" API?
Posted by Frank Zhang <Fr...@citrix.com>.
I think it's better to implement the feature first. Current HTTP layer of CloudStack is not REST ready, what I mean is you can not add your endpoint as convenient as in popular MVC like Spring MVC, ruby Rails, java Grails or GlassFish jersey which you mentioned before.
So I am afraid that it's hard if you want do something like GET /vm/vm_uuid?state=Running
For the query string, instead of inventing our pattern, I suggest following filter API of AWS API, it has answered our question.
> -----Original Message-----
> From: Min Chen [mailto:min.chen@citrix.com]
> Sent: Monday, November 05, 2012 4:19 PM
> To: cloudstack-dev@incubator.apache.org; Alena Prokharchyk
> Subject: Re: Should we have separate "Count" API?
>
> Yes, those are clean REST Urls. But do we have plan to convert our current
> API url to standard REST?
>
> -min
>
> On 11/5/12 4:12 PM, "Chiradeep Vittal" <Ch...@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" <mi...@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
> >><Al...@citrix.com>>
> >>Date: Monday, November 5, 2012 3:43 PM
> >>To:
> >>"cloudstack-dev@incubator.apache.org<mailto:cloudstack-
> dev@incubator.a
> >>pac
> >>h
> >>e.org>"
> >><cloudstack-dev@incubator.apache.org<mailto:cloudstack-
> dev@incubator.a
> >>pac
> >>h
> >>e.org>>, Min Chen <mi...@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 <mi...@citrix.com>>
> >>Reply-To:
> >>"cloudstack-dev@incubator.apache.org<mailto:cloudstack-
> dev@incubator.a
> >>pac
> >>h
> >>e.org>"
> >><cloudstack-dev@incubator.apache.org<mailto:cloudstack-
> dev@incubator.a
> >>pac
> >>h
> >>e.org>>
> >>To:
> >>"cloudstack-dev@incubator.apache.org<mailto:cloudstack-
> dev@incubator.a
> >>pac
> >>h
> >>e.org>"
> >><cloudstack-dev@incubator.apache.org<mailto:cloudstack-
> dev@incubator.a
> >>pac
> >>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
> >>
> >
Re: Should we have separate "Count" API?
Posted by Alena Prokharchyk <Al...@citrix.com>.
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" <Ch...@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" <mi...@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
>><Al...@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 <mi...@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 <mi...@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
>>
>
>
Re: Should we have separate "Count" API?
Posted by Alena Prokharchyk <Al...@citrix.com>.
On 11/7/12 9:52 AM, "Alex Huang" <Al...@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.yadav@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 <Ni...@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" <Ch...@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" <mi...@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
>>>>> <Al...@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 <mi...@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 <mi...@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
>>>>>
>>>>
>>>
>>
>
>
RE: Should we have separate "Count" API?
Posted by Alex Huang <Al...@citrix.com>.
- 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.
- 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.yadav@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 <Ni...@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" <Ch...@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" <mi...@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
>>>> <Al...@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 <mi...@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 <mi...@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
>>>>
>>>
>>
>
Re: Should we have separate "Count" API?
Posted by Rohit Yadav <ro...@citrix.com>.
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 <Ni...@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" <Ch...@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" <mi...@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
>>>> <Al...@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 <mi...@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 <mi...@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
>>>>
>>>
>>
>
Re: Should we have separate "Count" API?
Posted by George Reese <ge...@enstratus.com>.
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 <Ni...@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.Mehta@citrix.com]
>> Sent: Tuesday, November 06, 2012 06:08 PM
>> To: cloudstack-dev@incubator.apache.org <cl...@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" <Ch...@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" <mi...@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
>>>>> <Al...@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 <mi...@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 <mi...@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
>
RE: Should we have separate "Count" API?
Posted by Kishan Kavala <Ki...@citrix.com>.
Yes, listAccounts is not admin only. Any user can make listAccounts API call. But the response will vary based on the user privilege. Admin can list all accounts. Domain admin can only list accounts that belong to the particular domain.
> -----Original Message-----
> From: Nitin Mehta [mailto:Nitin.Mehta@citrix.com]
> Sent: Tuesday, 6 November 2012 6:58 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Should we have separate "Count" API?
>
>
>
> 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.Mehta@citrix.com]
> > Sent: Tuesday, November 06, 2012 06:08 PM
> > To: cloudstack-dev@incubator.apache.org
> > <cl...@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" <Ch...@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" <mi...@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
> >>>>
> <Al...@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
> <mi...@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 <mi...@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
> >>>>
> >>>
> >>
> >
Re: Should we have separate "Count" API?
Posted by Nitin Mehta <Ni...@citrix.com>.
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.Mehta@citrix.com]
> Sent: Tuesday, November 06, 2012 06:08 PM
> To: cloudstack-dev@incubator.apache.org <cl...@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" <Ch...@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" <mi...@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
>>>> <Al...@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 <mi...@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 <mi...@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
>>>>
>>>
>>
>
Re: Should we have separate "Count" API?
Posted by Vijaykumar Natarajan <vi...@citrix.com>.
Isn't listAccounts available to an admin only?
----- Original Message -----
From: Nitin Mehta [mailto:Nitin.Mehta@citrix.com]
Sent: Tuesday, November 06, 2012 06:08 PM
To: cloudstack-dev@incubator.apache.org <cl...@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" <Ch...@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" <mi...@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
>>> <Al...@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 <mi...@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 <mi...@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
>>>
>>
>
Re: Should we have separate "Count" API?
Posted by Nitin Mehta <Ni...@citrix.com>.
+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" <Ch...@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" <mi...@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
>>> <Al...@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 <mi...@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 <mi...@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
>>>
>>
>
Re: Should we have separate "Count" API?
Posted by Vijaykumar Natarajan <vi...@citrix.com>.
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
On 11/6/12 5:42 AM, "Chiradeep Vittal" <Ch...@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" <mi...@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
>><Al...@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 <mi...@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 <mi...@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
>>
>
Re: Should we have separate "Count" API?
Posted by Min Chen <mi...@citrix.com>.
Yes, those are clean REST Urls. But do we have plan to convert our current
API url to standard REST?
-min
On 11/5/12 4:12 PM, "Chiradeep Vittal" <Ch...@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" <mi...@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
>><Al...@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 <mi...@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 <mi...@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
>>
>
Re: Should we have separate "Count" API?
Posted by Chiradeep Vittal <Ch...@citrix.com>.
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" <mi...@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
><Al...@citrix.com>>
>Date: Monday, November 5, 2012 3:43 PM
>To:
>"cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apach
>e.org>"
><cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apach
>e.org>>, Min Chen <mi...@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 <mi...@citrix.com>>
>Reply-To:
>"cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apach
>e.org>"
><cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apach
>e.org>>
>To:
>"cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apach
>e.org>"
><cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apach
>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
>
Re: Should we have separate "Count" API?
Posted by Min Chen <mi...@citrix.com>.
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 <Al...@citrix.com>>
Date: Monday, November 5, 2012 3:43 PM
To: "cloudstack-dev@incubator.apache.org<ma...@incubator.apache.org>" <cl...@incubator.apache.org>>, Min Chen <mi...@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 <mi...@citrix.com>>
Reply-To: "cloudstack-dev@incubator.apache.org<ma...@incubator.apache.org>" <cl...@incubator.apache.org>>
To: "cloudstack-dev@incubator.apache.org<ma...@incubator.apache.org>" <cl...@incubator.apache.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
Re: Should we have separate "Count" API?
Posted by Alena Prokharchyk <Al...@citrix.com>.
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 <mi...@citrix.com>>
Reply-To: "cloudstack-dev@incubator.apache.org<ma...@incubator.apache.org>" <cl...@incubator.apache.org>>
To: "cloudstack-dev@incubator.apache.org<ma...@incubator.apache.org>" <cl...@incubator.apache.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