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'kīмсhī-∨м', 'template': u'/templates/test'}
    inst.vms_create(params)
    rollback.prependDefer(self._rollback_wrapper, inst.vm_delete,
                          u'kīмсhī-∨м')

    inst.vm_start(u'kīмсhī-∨м')
    rollback.prependDefer(self._rollback_wrapper, inst.vm_stop,
                          u'kīмсhī-∨м')

    inst.vm_delete(u'kīмсhī-∨м')

    vms = inst.vms_get_list()
    self.assertFalse(u'kīмсhī-∨м' 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'kīмсhī-∨м')" 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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel