cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <>
Subject RE: [VOTE] Enforcing UUID string in API query
Date Fri, 28 Dec 2012 04:19:20 GMT
Nitin, I don't understand you question, pre 3.x objects, what are those? AKAIK CloudStack upgrade
to 4.1 would have an upgrade path which would populate all tables with missing UUID fields,
this is necessary for response view etc. as response objects always have uuids. Therefore,
all objects will also have UUIDs.

Regex would be much faster and only O(k) (k is max no. of params that have CommandType UUID
and cal. of one field would be only O(1)) as UUID would be 32 char long, than string comparison
or splitting/comparision and the blunt way of throwing the string over Long value conversion
will make it not even slow but will cause exception. Share any fast and secure way? One fast
but insecure method is to try converting the string to long and if it fails assume it was

            try {
                internalId = Long.parseLong(uuid);
            } catch(NumberFormatException e) {
                // In case regex failed, and it's still uuid string
                internalId = null;
            if (internalId != null)
                return internalId;
            else { /*translate uuid logic here */}


From: Nitin Mehta []
Sent: Friday, December 28, 2012 9:08 AM
Subject: Re: [VOTE] Enforcing UUID string in API query

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];a=commit;h=623e7389ef0b2923b7859629cd70406e2e471525
> Regards.
> On 27-Dec-2012, at 2:04 PM, Will Chan <> 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 []
>>> Sent: Thursday, December 27, 2012 12:44 PM
>>> To:
>>> Cc:
>>> 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 []
>>>> Sent: Thursday, December 27, 2012 12:11 PM
>>>> To:
>>>> Cc:
>>>> 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.

View raw message