cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mathias Mullins <mathias.mull...@citrix.com>
Subject Re: [VOTE] Enforcing UUID string in API query
Date Thu, 27 Dec 2012 21:01:50 GMT
-1 - Agree with Will on this.

Matt Mullins





On 12/27/12 3:45 PM, "Will Chan" <will.chan@citrix.com> wrote:

>-1
>
>You will end up breaking anyone that has written any scripts/plugins/apps
>on top of pre 3.x  CS.  Since UUID was introduced in 3.0, you should only
>accept the following:
>
>- All first class objects created before 3.0 should accept an normal
>internal ID.
>- All first class objects created after 3.0 should accept UUID only.  Any
>attempts to query these objects using the internal ID should result in
>"object not found".
>
>By forcing everything to take in a UUID means you will have to force many
>of CS's integration on top of pre 3.0 CS to re-map their internal IDs.
>This is just not practical.
>
>Will
>
>> -----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
>> 4e04a-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