This RFE is about consistent support of search query across all resource collections (both top-level and nested ones). Currently, only top-level resource collections support passing the search query. For example, top-level "datacenters" collection allows "search" parameter: GET /ovirt-engine/api/datacenters?search=... However, nested (sub)collection "clusters" does not allow "search" parameter: GET /ovirt-engine/api/datacenters/{id}/clusters?search=... I assume this will involve some backend infra refactoring, but I think it's worth the effort - it will improve REST SDKs and therefore UI as well (i.e. server-side sorting supported for all entities via search query).
but clusters is also a top level collection in itself, allowing to do the search via /ovirt-engine/api/clusters?search= ?
(In reply to Itamar Heim from comment #1) > but clusters is also a top level collection in itself, allowing to do the > search via /ovirt-engine/api/clusters?search= ? Yes, clusters are also exposed via top-level resource collection (in which case the search query parameter is supported): GET /ovirt-engine/api/clusters?search=... From REST client perspective: /ovirt-engine/api/clusters returns all clusters, whereas: /ovirt-engine/api/datacenters/{id}/clusters returns clusters constrained by "owner" resource, i.e. clusters for given datacenter. You are right that "clusters for given datacenter" could be queried like: /ovirt-engine/api/clusters?search=<datacenter_constraint> However, this sounds more like workaround than proper solution to me, as it means that existence of some functionality (search query) depends on resource's position within the logical hierarchy. In other words, top-level collection supports it, whereas nested collection doesn't support it, for the *same* type of resource. If all types of resources would be exposed as top-level collections, we could use these top-level collections. Not sure if this is the case today. Juan, if you have any comments or suggestions, please advise.
I agree that adding support for searching in non top-level collections makes sense, and makes the RESTAPI more consistent. However, it requires a non trivial amount of work. Take into account that the RESTAPI uses the same search mechanism used by the GUI search bar, so for almost all non top-level collection search there exist a corresponding top-level collection search. For example, the following search currently doesn't exist: a) /datacenters/{datacenter:id}/clusters?search={query} But it can be translated into this: b) /clusters?search=datacenter.name={datacenter.name} and {query} Note that unfortunately we don't support search based on "id", only on "name", so this isn't possible right now: the client has to do the translation. I'd suggest the following approach: 1. Add search based on "id" to the backend, so that the translation from query "a" to query "b" can be performed in a simple way: a) /datacenters/{datacenter:id}/clusters?search={query} b) /clusters?search=datacenter.id={datacenter:id} and {query} 2. Add this translation capability to the JavaScript SDK, or to oVirt.js, so that the caller will be able to use the search capability for non top-level collections even if the RESTAPI doesn't support it. 3. Implement the search capability for non top-level collections in the RESTAPI, probably using the same query translation technique. Doing things this way means that steps 2 and 3 can make progress (or not) independently.
> Note that unfortunately we don't support search based on "id", only on > "name", so this isn't possible right now: the client has to do the > translation. I think this is due to historical reasons; in WebAdmin UI, users typically search based on "name" rather than "id". More generally, requirements for search backend were (I think) driven mostly by WebAdmin UI. > I'd suggest the following approach: > > 1. Add search based on "id" to the backend, so that the translation from > query "a" to query "b" can be performed in a simple way: > > a) /datacenters/{datacenter:id}/clusters?search={query} > b) /clusters?search=datacenter.id={datacenter:id} and {query} +1 > 2. Add this translation capability to the JavaScript SDK, or to oVirt.js, so > that the caller will be able to use the search capability for non top-level > collections even if the RESTAPI doesn't support it. +1 > 3. Implement the search capability for non top-level collections in the > RESTAPI, probably using the same query translation technique. If all resource types would be exposed via top-level collections, we can use translation technique mentioned in step 1. Client APIs such as JavaScript SDK could make it completely transparent to the user. It is up to REST API maintainers to decide if they ultimately want to support & implement search parameter for all (top-level + non-top-level) collections. From client perspective, workaround mentioned in step 1 would be sufficient, assuming it could be applied to all resource types.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Closing as WONTFIX. Not relevant at the moment, and we have started work around it in the past, but we've had too many issues. The effort doesn't worth the benefit.