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.

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.

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" <alo...@redhat.com>
> To: "Itamar Heim" <ih...@redhat.com>
> Cc: "Juan Hernandez" <jhern...@redhat.com>, "arch" <a...@ovirt.org>, "VDSM 
> Project Development"
> <vdsm-devel@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" <ih...@redhat.com>
> > To: "Alon Bar-Lev" <alo...@redhat.com>
> > Cc: "Juan Hernandez" <jhern...@redhat.com>, "arch"
> > <a...@ovirt.org>, "VDSM Project Development"
> > <vdsm-devel@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" <jhern...@redhat.com>
> > >> To: "Alon Bar-Lev" <alo...@redhat.com>
> > >> Cc: "Itamar Heim" <ih...@redhat.com>, "arch" <a...@ovirt.org>,
> > >> "VDSM Project Development"
> > >> <vdsm-devel@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" <ih...@redhat.com>
> > >>>> To: "Alon Bar-Lev" <alo...@redhat.com>
> > >>>> Cc: "Saggi Mizrahi" <smizr...@redhat.com>, "arch"
> > >>>> <a...@ovirt.org>, "VDSM Project Development"
> > >>>> <vdsm-devel@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" <smizr...@redhat.com>
> > >>>>>> To: "arch" <a...@ovirt.org>, "VDSM Project Development"
> > >>>>>> <vdsm-devel@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@lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> 
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to