On 02/27/2014 05:54 PM, Crístian Viana wrote:
Am 27-02-2014 14:29, schrieb Aline Manera:
> Even using UUID, the rollback problem will still exist.
Using UUID would be enough.
Take a look at the code:
with RollbackContext() as rollback:
params = {'name': u'test', 'disks': []}
inst.templates_create(params)
rollback.prependDefer(inst.template_delete, 'test')
params = {'name': u'ki-??hi--??', 'template':
u'/templates/test'}
inst.vms_create(params)
* rollback.prependDefer(self._rollback_wrapper, inst.vm_delete,**
** u'ki-??hi--??')*
inst.vm_start(u'ki-??hi--??')
* rollback.prependDefer(self._rollback_wrapper, inst.vm_stop,**
** u'ki-??hi--??')*
inst.vm_delete(u'ki-??hi--??')
vms = inst.vms_get_list()
self.assertFalse(u'ki-??hi--??' in vms)
Suppose the two lines defer commands like
"inst.vm_delete_by_uuid(uuid)". Even if something fails, if the VMs'
names change, or if everything executes successfully, they would stop
and delete the VM in the end of the transaction.
I agree with you that UUID works ... but I see it solving the problem
when VM is renamed, only.
By the way, the command "inst.vm_delete(u'ki-??hi--??')" will delete
the VM and will obviously lead to an error when the deferred
"vm_delete" is executed, because the VM will not exist anymore.
Yeap, this was the root cause of the bug... and would happen using UUID
or 'name'.
I understand that rollback_wrapper function is not so elegant ... but,
in fact, it is just "checking" if the vm exists in order to does not
break rollback, which does not have its behaviour changed (maybe I named
the function wrongly).
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel