Long ago it was not enforced and then changed.
The motivation for the enforcing as I recall was that for VMs this was also the 
guest system ID. I don't know if this is the case now days.


Sent from my iPhone, please excuse any typos.

ב-31 באוג 2012, בשעה 00:19, Saggi Mizrahi <smizr...@redhat.com> כתב/ה:

> 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.
> _______________________________________________
> Arch mailing list
> a...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
vdsm-devel mailing list

Reply via email to