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.ya...@citrix.com] >Sent: Thursday, December 27, 2012 3:43 PM >To: cloudstack-us...@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.c...@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.hu...@citrix.com] >>> Sent: Thursday, December 27, 2012 12:44 PM >>> To: cloudstack-dev@incubator.apache.org >>> Cc: cloudstack-us...@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.ya...@citrix.com] >>>> Sent: Thursday, December 27, 2012 12:11 PM >>>> To: cloudstack-dev@incubator.apache.org >>>> Cc: cloudstack-us...@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. >>>> >>
