Description of problem: vm is removed unexpectedly. When Filter = True Version-Release number of selected component (if applicable): rhevm-cli-3.5.0.5-1.el6ev.noarch How reproducible: always Steps to Reproduce: 1. rhevm-shell -r -c -l "https://xx.xx.xx.xx:443/api/" -u "admin@internal" -I -F -S 3600 2. [RHEVM shell (connected)]# add vm --name testvm02 --cluster-id 0881c47e-191d-4ff9-9ba5-344d1e7d3f46 --template-id 00000000-0000-0000-0000-000000000000 3. list vms id : 77e1e939-3863-4dd5-adb4-66715516ff6e name : testvm02 4. remove vm blablabla Actual results: job-id : a21cd9f8-be21-40e7-9151-2549018eb8f9 status-state: complete the vm names testvm02 is deleted Expected results: ERROR no vm name called blablabla Additional info:
This happens because before actually performing the remove the CLI performs a search to locate the VM, for example: GET /ovirt-engine/api/vms?search=name%3Dblablabla Filter: True But the RESTAPI server ignores the "search" parameter when the "Filter: True" header is used, it will instead return all the virtual machines that the user has permissions for. In this case it will return the information corresponding to the "testvm02" virtual machine: <vms> <vm id="77e1e939-3863-4dd5-adb4-66715516ff6e"> <-- This is the id of testvm02 <name>testvm02</name> ... </vm> ... </vms> The the CLI sends the DELETE request, to the resource returned in the previous step.
the reasons for this issue are: 1. wrong behaviour of engine rest-api 2. cli that running in user mode, but assumes admin when filter=true, api should not return any object at all, as ?search is not supported in the user mode, as about cli, when filter=true, it should not use ?search to locate the resource by name, but listing of all resources via list() + kwargs filtering on client side so no obj will be returned if no kwargs match has found (unfortunately cli code was written way before user-api, thus it not addresses issue arise in this mode), so i'd split this BZ in two -> rest-api / cli
Bug 1155967 tracks the issue in the RESTAPI.
The complete fix for this bug should be adding support for the "search" parameter to the backend, but as that will take a long time, we will are introducing in the Python SDK an additional filtering of the results returned by the server, so that objects that don't match the name given by the user (or the alias, for disks) are discarded. This has been done in upstream release 3.5.0.8, so to fix this bug dowstream we will need to rebase.
Created attachment 956267 [details] Proposed patch to fix the bug
Created attachment 956676 [details] Proposed patch to fix the bug
tested on vt12
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-0183.html