Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of Nitin.Mehta@citrix.com
 designates 203.166.19.134 as permitted sender)
From: Nitin Mehta <Nitin.Mehta@citrix.com>
To: "cloudstack-users@incubator.apache.org"
	<cloudstack-users@incubator.apache.org>
CC: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>
Date: Fri, 28 Dec 2012 09:08:09 +0530
Subject: Re: [VOTE] Enforcing UUID string in API query
Thread-Topic: [VOTE] Enforcing UUID string in API query
Thread-Index: Ac3krMS2V89qkUHLQAGtiQsX1U81jQ==
Message-ID: <546D0400-6D4F-4845-B7A0-B4439524D66C@citrix.com>
References: <8E81A714-9DA8-4A67-8421-EB256932D027@citrix.com>
 <B1DF26ECC0458748AC97CECE2DA98D41012FA385E447@SJCPMAILBOX01.citrite.net>
 <61AE1E2837A06D4A8E98B796183842D401293587B9FA@SJCPMAILBOX01.citrite.net>
 <C3B773AF-B7BF-41D1-BAD8-946F02B3C260@citrix.com>
In-Reply-To: <C3B773AF-B7BF-41D1-BAD8-946F02B3C260@citrix.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi Rohit,=20

I didn't understand the rationale behind this. Can you please explain ? tha=
nks=20

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 ap=
iserver to make it backward compatible;
>=20
> - For all pre 3.x apis, both uuid, internal id can be used, all pre 3.x a=
pis don't have since field in their annotation.
> - For post 3.x apis, uuid param checking is enforced.
>=20

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

> 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.
>=20
> [1] https://git-wip-us.apache.org/repos/asf?p=3Dincubator-cloudstack.git;=
a=3Dcommit;h=3D623e7389ef0b2923b7859629cd70406e2e471525
>=20
> Regards.
>=20
> On 27-Dec-2012, at 2:04 PM, Will Chan <will.chan@citrix.com> wrote:
>=20
>> I personally do not like flags changing syntax which is what it is in th=
is 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 bac=
kwards compatibility and also the fact that both ways needs to be tested an=
d validated.
>>=20
>> Will
>>=20
>>> -----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
>>>=20
>>> 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?
>>>=20
>>> --Alex
>>>=20
>>>> -----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
>>>>=20
>>>> Hi,
>>>>=20
>>>> 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.
>>>>=20
>>>> You may vote by:
>>>> +1 Agree
>>>> 0  No opinion
>>>> -1 Disagree
>>>>=20
>>>> Some context and description:
>>>>=20
>>>> 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.
>>>>=20
>>>> At present an API can be queried with both ids, for example for param
>>>> domainid using uuid in 1 and using id in 2:
>>>>=20
>>>> 1.
>>>>=20
>>> http://localhost:8080/client?command=3DlistResourceLimits&domainid=3D86=
6
>>> 4e
>>>> 0
>>>> 4a-9931-4765-b3456e6888d0fa1d
>>>> 2.
>>> http://localhost:8080/client?command=3DlistResourceLimits&domainid=3D1
>>>>=20
>>>> 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.
>>>>=20
>>>> Regards.
>>>>=20
>>=20
>=20