Created attachment 758820 [details] ## Logs rhevm Description of problem: Missing description, during detach VM from vm pool action Version-Release number of selected component (if applicable): RHEVM 3.2 - SF17.1 environment: RHEVM: rhevm-3.2.0-11.28.el6ev.noarch VDSM: vdsm-4.10.2-21.0.el6ev.x86_64 LIBVIRT: libvirt-0.10.2-18.el6_4.5.x86_64 QEMU & KVM: qemu-kvm-rhev-0.12.1.2-2.355.el6_4.3.x86_64 SANLOCK: sanlock-2.6-2.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1. Crete VM pool 2. Via PythonSDK detach VM from VM pool with wrong name or detach VM from pool that is not in relevant pool. Actual results: Get an error with missing description. Via log, impossible to know, on which VM name I failed Expected results: In log get VM name Impact on user: Workaround: Additional info: /var/log/ovirt-engine/engine.log 2013-06-06 10:59:15,956 WARN [org.ovirt.engine.core.bll.RemoveVmFromPoolCommand] (ajp-/127.0.0.1:8702-19) [5e7a57f7] CanDoAction of action RemoveVmFromPool failed. Reasons:VM_POOL_CANNOT_DETACH _VM_NOT_ATTACHED_TO_POOL 2013-06-06 10:59:15,957 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (ajp-/127.0.0.1:8702-19) Operation Failed: [Cannot detach VM from pool. VM is not attached to the VM -Pool.] /var/log/vdsm/vdsm.log
this is how the system works, if you do some action on object X, and the action can't be executed, you know the object is X. some examples: try to remove up vm: "Cannot remove VM. VM is running." try to remove up host: "Cannot remove Host. Host is operational. Please switch Host to Maintenance mode first." and so on, not only for remove flows, any action in the system that fails the can-do-action phase will not mention the object name, it is known to the user.. it might worth adding some infrastucture to log also the object name/id that is related to the command, not for this command only.
I definitely agree that it calls for more general solution, but this is out of scope of this bug. I did it this way, because I'm seeing this approach in more backend commands. So what do you suggest, Omer? To abandon seggested mini-patch and think about something more general?
The solution of this bug requires more general approach that affects all commands (as briefly suggested in the comment 1). Therefore a new bug should be filed that covers this.