incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nitin Mehta <Nitin.Me...@citrix.com>
Subject Re: [VOTE] Enforcing UUID string in API query
Date Fri, 28 Dec 2012 03:38:09 GMT
Hi Rohit, 

I didn't understand the rationale behind this. Can you please explain ? thanks 

On 28-Dec-2012, at 5:12 AM, Rohit Yadav wrote:

> 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.
> 

Can you please explain me the relation with 3.x api's ? I guess what Will said that all the
objects (resources) created pre 3.x will have just ID populated and not the UUID. Also I saw
the code and there is regex check for UUID. I am afraid that will  impact the performance.


> 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