[vdsm] [RFC] Implied UUIDs in API

Mon Sep 3 10:06:25 UTC 2012

On 09/02/2012 10:32 AM, Ayal Baron wrote:
> ----- 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.

for identities the caller pass, I think vdsm can use string and engine 
can use uuid as that string.
but for identities generated by vdsm (task id's, maybe tomorrow image 
id's, etc.) - there is a huge different between "not validating" and 
formally using uuid's as the expected type to not throw engine expecting 
a uuid for these fields.

>
>> 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
>>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>