incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <rohit.ya...@citrix.com>
Subject Re: [VOTE] Enforcing UUID string in API query
Date Thu, 27 Dec 2012 23:42:35 GMT
Alright, spoke with tsp on irc on testing methods etc. I fixed [1] the apiserver to make it
backward compatible;

- For all pre 3.x apis, both uuid, internal id can be used, all pre 3.x apis don't have since
field in their annotation.
- For post 3.x apis, uuid param checking is enforced.

The response (xml or json) always had uuid (and not internal id) since 3.x which is fine with
everyone and I fail to understand the case.

[1] https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=623e7389ef0b2923b7859629cd70406e2e471525

Regards.

On 27-Dec-2012, at 2:04 PM, Will Chan <will.chan@citrix.com> wrote:

> I personally do not like flags changing syntax which is what it is in this case.  A flag
to support whether a feature like "snapshots" is supported is ok.  A flag to say whether ID
or UUID is accepted means issues with backwards compatibility and also the fact that both
ways needs to be tested and validated.
> 
> Will
> 
>> -----Original Message-----
>> From: Alex Huang [mailto:Alex.Huang@citrix.com]
>> Sent: Thursday, December 27, 2012 12:44 PM
>> To: cloudstack-dev@incubator.apache.org
>> Cc: cloudstack-users@incubator.apache.org
>> Subject: RE: [VOTE] Enforcing UUID string in API query
>> 
>> Sorry I don't understand why it needs to be a vote.  Why can't we just offer
>> a flag to turn it on and off?
>> 
>> --Alex
>> 
>>> -----Original Message-----
>>> From: Rohit Yadav [mailto:rohit.yadav@citrix.com]
>>> Sent: Thursday, December 27, 2012 12:11 PM
>>> To: cloudstack-dev@incubator.apache.org
>>> Cc: cloudstack-users@incubator.apache.org
>>> Subject: [VOTE] Enforcing UUID string in API query
>>> 
>>> Hi,
>>> 
>>> I'm asking for the community to vote if they want to enforce UUID
>>> string to be used in parameters while querying an API. This would
>>> break any client or script that uses internal ID. AFAIK api response
>>> (json or xml, since 3.x for sure) always have had UUIDs so if any
>>> client/script that uses apis to query entities and base their further
>>> operations using ids from the response(s) should be fine.
>>> 
>>> You may vote by:
>>> +1 Agree
>>> 0  No opinion
>>> -1 Disagree
>>> 
>>> Some context and description:
>>> 
>>> CloudStack uses internal IDs which are long ints and they have a
>>> mapping between this ID and the external ID or UUID which is a random
>>> string of characters.
>>> There are DAO classes which provides a mechanism to query a particular
>>> table(s) and do other operations. There are VO objects which can hold
>>> content of a row. In most VO objects a method getId() would return a
>>> long int number which is the internal ID of that entity and they would
>>> have a
>>> getUuid() which returns a unique random string of chars.
>>> 
>>> At present an API can be queried with both ids, for example for param
>>> domainid using uuid in 1 and using id in 2:
>>> 
>>> 1.
>>> 
>> http://localhost:8080/client?command=listResourceLimits&domainid=866
>> 4e
>>> 0
>>> 4a-9931-4765-b3456e6888d0fa1d
>>> 2.
>> http://localhost:8080/client?command=listResourceLimits&domainid=1
>>> 
>>> For querying using id, the caller should have idea of the id for that
>>> entity and which is only possible if they have access to CloudStack's
>>> database. There is no other way of knowing an entity's id, only uuids
>>> are sent as ids in the response.
>>> 
>>> Regards.
>>> 
> 


Mime
View raw message