[vdsm] [RFC] Implied UUIDs in API

[Alon Bar-Lev]

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Juan Hernandez" <jhernand at redhat.com>, "arch" <arch at ovirt.org>, "VDSM Project Development"
> <vdsm-devel at lists.fedorahosted.org>
> Sent: Friday, August 31, 2012 4:22:14 PM
> Subject: Re: [vdsm] [RFC] Implied UUIDs in API
> 
> 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 guess you want me to analyse our current implementation and find optimizations that can be done... or in different words, find entities we abuse now... :)
 
> 
> >
> > 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.
> >
> 
> 
>