[vdsm] [RFC] Implied UUIDs in API

[Juan Hernandez]

On 08/31/2012 11:27 AM, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "Saggi Mizrahi" <smizrahi at redhat.com>, "arch" <arch at ovirt.org>, "VDSM Project Development"
>> <vdsm-devel at lists.fedorahosted.org>
>> Sent: Friday, August 31, 2012 12:23:38 PM
>> Subject: Re: [vdsm] [RFC] Implied UUIDs in API
>>
>> On 08/31/2012 12:33 AM, Alon Bar-Lev wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Saggi Mizrahi" <smizrahi at redhat.com>
>>>> To: "arch" <arch at ovirt.org>, "VDSM Project Development"
>>>> <vdsm-devel at lists.fedorahosted.org>
>>>> Sent: Friday, August 31, 2012 12:19:46 AM
>>>> Subject: [vdsm] [RFC] Implied UUIDs in API
>>>>
>>>> Hi, in the API a lot of IDs get passed around are UUIDs.
>>>> The point is that as long as you are not the entity generating the
>>>> UUIDs the fact that these are UUIDs have no real significance to
>>>> you.
>>>> I suggest removing the validation of UUIDs from the receiving end.
>>>> There is no real reason to make sure these are real UUIDs.
>>>> It's another restriction we can remove from the interface
>>>> simplifying
>>>> the code and the interface.
>>>>
>>>> Just to be clear I'm not saying that we should stop using UUIDs.
>>>> For example, vdsm will keep generating task IDs as UUIDs. But the
>>>> documentation will state that it could be *any* string value.
>>>> If for some reason we choose to change the format of task IDs.
>>>> There
>>>> will be no need to change the interface.
>>>>
>>>> The same goes for VM IDs. Currently the engine uses UUIDs but
>>>> there
>>>> is no reason for VDSM to enforce this and limit the engine from
>>>> ever
>>>> changing it in the future and using other string values.
>>>
>>> I agree that UUID is just a method of generating unique strings,
>>> there is no reason to validate the value nor the format.
>>
>> I'm with daniel on this one - knowing a field is a uuid makes it
>> easier
>> to deal with in the db and code around it compared to a string
>> (stored
>> binary instead of string representation, etc.)
>>
> 
> Why to store binary?

An UUID stored in its binary format takes 16 bytes. Stored as an string
it takes 36 bytes, and more than 72 bytes in memory in the engine. The
amount of CPU needed to create/compare/etc is proportional.

The engine takes advantage of this and uses an specialized UUID class
and a specialized database type to manage them. If we change to
arbitrary strings then a *lot* of changes have to be done to the engine.

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.