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

> 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.

|: 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 :|
vdsm-devel mailing list

Reply via email to