Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Not A Problem
-
pre-4.0.0
-
Security Level: Public (Anyone can view this level - this is the default.)
-
None
-
Management server : Rhel 6.3 Host : KVM (Rhel 6.3) & KVM (Ubuntu 12.04) ASF build : http://jenkins.cloudstack.org/job/build-4.0-rhel63/163/artifact/CloudStack-oss-4.0.0-163.tar.bz2
Description
Description :
=======================
listCapacity API is not able to list the Cluster-wide capacities when parameters "clusterid" and "sortby" are used together.
Steps :
=======================
Deploy an advanced zone CS setup with 2 KVM clusters and list the capacities of a particular cluster , sorted by usage , using listCapacity API
http://10.102.125.201:8096/client/api?command=listCapacity&sortby=Usage&clusterid=1
Expected Behaviour :
=======================
The capacities of the particular cluster should be listen in order of their usage.
Observed Behaviour :
=======================
1. When the API in step 1 is executed in the browser, we get following response
http://10.102.125.201:8096/client/api?command=listCapacity&sortby=Usage&clusterid=1
This XML file does not appear to have any style information associated with it. The document tree is shown below.
<listcapacityresponse cloud-stack-version="4.0.0.20120925080636">
<errorcode>431</errorcode>
<cserrorcode>4490</cserrorcode>
<errortext>Currently clusterId param is not suppoerted</errortext>
</listcapacityresponse>
2. When the API is run without the "sortby" parameter, we get the list of capacities for that cluster in response.
http://10.102.125.201:8096/client/api?command=listCapacity&clusterid=1
This XML file does not appear to have any style information associated with it. The document tree is shown below.
<listcapacityresponse cloud-stack-version="4.0.0.20120925080636"><count>4</count><capacity><type>0</type><zoneid>bd0e60bf-2e4a-4d5a-99ae-2d3aad20c851</zoneid><zonename>zone-1</zonename><podid>ffdf7e60-05bb-4632-b10e-8d26f68dda9e</podid><podname>pod-1</podname><clusterid>6a40d3c7-48eb-497b-a7f8-9c61349ad35c</clusterid><clustername>c1</clustername><capacityused>5771362304</capacityused><capacitytotal>16707985408</capacitytotal><percentused>34.54</percentused></capacity><capacity><type>1</type><zoneid>bd0e60bf-2e4a-4d5a-99ae-2d3aad20c851</zoneid><zonename>zone-1</zonename><podid>ffdf7e60-05bb-4632-b10e-8d26f68dda9e</podid><podname>pod-1</podname><clusterid>6a40d3c7-48eb-497b-a7f8-9c61349ad35c</clusterid><clustername>c1</clustername><capacityused>5500</capacityused><capacitytotal>19144</capacitytotal><percentused>28.73</percentused></capacity><capacity><type>3</type><zoneid>bd0e60bf-2e4a-4d5a-99ae-2d3aad20c851</zoneid><zonename>zone-1</zonename><podid>ffdf7e60-05bb-4632-b10e-8d26f68dda9e</podid><podname>pod-1</podname><clusterid>6a40d3c7-48eb-497b-a7f8-9c61349ad35c</clusterid><clustername>c1</clustername><capacityused>39380865024</capacityused><capacitytotal>15739424079872</capacitytotal><percentused>0.25</percentused></capacity><capacity><type>2</type><zoneid>bd0e60bf-2e4a-4d5a-99ae-2d3aad20c851</zoneid><zonename>zone-1</zonename><podid>ffdf7e60-05bb-4632-b10e-8d26f68dda9e</podid><podname>pod-1</podname><clusterid>6a40d3c7-48eb-497b-a7f8-9c61349ad35c</clusterid><clustername>c1</clustername><capacityused>4564830912512</capacityused><capacitytotal>7869712039936</capacitytotal><percentused>58.01</percentused></capacity></listcapacityresponse>