[Kimchi-devel] [PATCH V2 6/6] Fix Kimchi vm tests according to new messages sent from backend

[Rodrigo Trujillo]

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 at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140227/dfc91568/attachment.html>