[vdsm] [RFC] Implied UUIDs in API

[Alon Bar-Lev]

----- 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.

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.