On Thu, Aug 30, 2012 at 02:23:54PM -0700, Daniel P. Berrange wrote: > 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.
Dan, you are correct. vmId==libvirt's domain uuid. _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
