[vdsm] [RFC] Implied UUIDs in API

[Itamar Heim]

On 08/31/2012 03:36 PM, Alon Bar-Lev wrote:
>
>
> ----- Original Message -----
>> From: "Juan Hernandez" <jhernand at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "Itamar Heim" <iheim at redhat.com>, "arch" <arch at ovirt.org>, "VDSM Project Development"
>> <vdsm-devel at lists.fedorahosted.org>
>> Sent: Friday, August 31, 2012 12:36:10 PM
>> Subject: Re: [vdsm] [RFC] Implied UUIDs in API
>>
>> 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.
>
> We are trying to reduce types of vdsm to simplify the VDSM-next API.
>
> I guess it will derive a lot of changes in the engine anyway...
>
> 32->72 bytes in memory of JVM is not something that I care, JVM is not optimized for memory use in any sense.

that doesn't mean you should abuse it. it's not a single item. its all 
the items.


>
> I am not sure that compare in database of binary or string has significant impact, if there is a proper indexing, and if foreign key is used to cascade.
>
> Regards,
> Alon.
>