incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kelcey Damage \(BT\)" <kel...@backbonetechnology.com>
Subject RE: [VOTE] Enforcing UUID string in API query
Date Fri, 28 Dec 2012 00:15:40 GMT
Hmm, I am going to vote +0 on this one. I see this as something that makes
sense for the future functionality of the CS API, but the fact it is such a
major change, it's hard for me to jump on it. I also very much dislike UUIDs
as they can be cumbersome and unwieldy to manage. The upside is, if we do
this now, we can get it out of the way.

+0

-kd


>-----Original Message-----
>From: Rohit Yadav [mailto:rohit.yadav@citrix.com]
>Sent: Thursday, December 27, 2012 3:43 PM
>To: cloudstack-users@incubator.apache.org
>Cc: cloudstack-dev@incubator.apache.org
>Subject: Re: [VOTE] Enforcing UUID string in API query
>
>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