[vdsm] [RFC] Implied UUIDs in API
Alon Bar-Lev
alonbl at redhat.com
Thu Aug 30 21:33:24 UTC 2012
----- 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.
Thanks,
Alon.
More information about the Arch
mailing list