Description of problem: The oVirt Engine API returns zero results on the search API if the max parameter is specified, even if there are disks that match. This returns one result: https://***/ovirt-engine/api//disks?case_sensitive=true&search=name%3Dtest_disk This returns zero results: https://***/ovirt-engine/api//disks?case_sensitive=true&max=1&search=name%3Dtest_disk How reproducible: Create a disk with a specific name and open the above engine URLs with proper credentials. Actual results: No disks are shown. Expected results: One disk should be shown.
the handling of max, search, and other parameters are a bit special in oVirt API. What's the use case? I'd suggest to filter on client side
The use case is to not query all disks in the oVirt engine, just the number you expect so you don't have to allocate a large amount of memory for potentially thousands of disks and transfer their details over the network. The max parameter is supported in the API, it should either be removed or fixed.
I'll explain the reason for the bug: Normally the search module in the Engine wholly handles search requests. Since the search module can not account for the disk-snapshots, it is insufficient in the case of disks. Therefore, a designated stored-procedure is used. However, in order not to lose the search functionality - i.e we still want the user to be able to filter results according to disk properties - the database is queried twice - once using the stored-procedure, and once using the search module. The results are intersected and returned. The problem is that 'max' is applied *before* the intersection - once for the stored-procedure results and once for the search results - and so the intersection is done on partial lists and may lose data - potentially even all data and return an empty lists. This can be solved in the API layer by deferring the application of 'max' until the intersection; i.e - get all results from the SP and all results from the search without applying 'max', intersect the lists and only then apply max. But this could be costly in terms of performance, as in some setups there maybe tens of thousands of disks, and they would all have to be retrieved. A more correct - but probably far more complicated - solution is to support such an intersection at the database level. I went over all searchable collections and this problem only applies to disks. However, this is true only for admin. Whenever a non-admin user uses the search module, there will always be behind-the-scenes an intersection between a stored-procedure and the search results - this is due to the fact that the search module does not support permissions, and stored-procedures do. So searching as a non-admin user and using max is, in the current state of things, expected not to work for any searchable collection
The documentation text flag should only be set after 'doc text' field is provided. Please provide the documentation text and set the flag to '?' again.
This bug has low overall severity and passed an automated regression suite, and is not going to be further verified by QE. If you believe special care is required, feel free to re-open to ON_QA status.