Bug 1962177
Summary: | Disk search API returns zero result if max parameter is specified | ||
---|---|---|---|
Product: | [oVirt] ovirt-engine | Reporter: | Janos Bonic <jpasztor> |
Component: | RestAPI | Assignee: | Ori Liel <oliel> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Guilherme Santos <gdeolive> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4.4.6 | CC: | bugs, michal.skrivanek, mperina |
Target Milestone: | ovirt-4.4.7 | Keywords: | ZStream |
Target Release: | 4.4.7.1 | Flags: | pm-rhel:
ovirt-4.4+
|
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | ovirt-engine-4.4.7.1 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2021-07-14 13:08:37 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Infra | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Janos Bonic
2021-05-19 13:02:01 UTC
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. |