+1 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.
Regards, Simon 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 firstname.lastname@example.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel