[vdsm] [RFC] Implied UUIDs in API

Sun Sep 2 07:32:18 UTC 2012

----- Original Message -----
> In my opinion the implications on the engine database storage are not
> relevant, the engine can still choose to store everything as UUID if
> it finds it more easier.
> The only change would be that VDMS wouldn't care if they are UUIDs or
> not. They can still *be* UUIDs.
> The only problem is that if other managers start creating entities
> you will have to be able to gracefully handle that in API responses.

Wrt db - nothing needs to change.  The value is determined by engine today and can go on being a UUID even if VDSM doesn't validate it to be one.

> 
> I also wonder why libvirt chose to validate UUIDs. Because as I said,
> as long as you don't generate them the fact that the are *possibly*
> unique is of no consequence to you. Seeing as the field comes to
> libvirt from an XML stream there is no real issue with parsing and
> putting it in a properly null terminated buffer.
> 

For fields on which underlying components apply limitations such as the VM ID passed to libvirt I think we should validate but note in the documentation that there is no guarantee that it is a UUID as implementation may change.

Wrt Daniel's comment about fixed length - I agree it is easier to deal with fixed length strings (we also rely on this in sanlock iirc) so I would keep a length limitation on the string.

> The main reason I want to rid away the UUID restriction is that I
> think that it will help us have namespacing.
> 
> As VDSM's API becomes open and the ovirt-engine less centralized it
> will be harder to know which VDSM side resources are owned by which
> managing entity.
> Being able to mangle in you data (eg.
> OVIRT_ENGINE_0003-321321-321321-3213) will make it easier to know
> which VMs, domains, storage connections, are owned by which entity
> without actually going into implementing access controls on VDSM
> resources.
> 
> Further more, subsystems that might generate IDs in a different way
> could be fitted more easily.
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "Itamar Heim" <iheim 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 9:52:33 AM
> > Subject: Re: [vdsm] [RFC] Implied UUIDs in API
> > 
> > 
> > 
> > ----- 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.
> > > >
> > > 
> > > 
> > > 
> > _______________________________________________
> > vdsm-devel mailing list
> > vdsm-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > 
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> 