[vdsm] [RFC] Implied UUIDs in API

[Dan Kenigsberg]

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.