[vdsm] [RFC] Implied UUIDs in API

Daniel P. Berrange berrange at redhat.com
Thu Aug 30 21:23:54 UTC 2012


On Thu, Aug 30, 2012 at 05:19:46PM -0400, Saggi Mizrahi wrote:
> 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.

IMHO it is worth having strict UUIDs in preference to arbitrary strings,
since their fixed size lets you deal with them more efficiently and
predictably.

> 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'm not sure this is correct. IIUC the vmId value is used set the <uuid>
element in the libvirt VM XML configuration, and libvirt will strictly
validate for a well formed UUID string.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|



More information about the Arch mailing list