Bug 1377359

Summary: [RFE] Possibility to request disks by multiple disk IDs
Product: [oVirt] ovirt-engine Reporter: Filip Krepinsky <fkrepins>
Component: RestAPIAssignee: Juan Hernández <juan.hernandez>
Status: CLOSED WONTFIX QA Contact: Pavel Stehlik <pstehlik>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.0.0CC: amureini, bugs, ylavi
Target Milestone: ---Keywords: FutureFeature
Target Release: ---Flags: juan.hernandez: ovirt-future?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-01-31 13:33:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Filip Krepinsky 2016-09-19 13:26:41 UTC
Description of problem:
Our mobile client moVirt needs to get disks of selected vm. This is done by either querying all disks or retrieving disks one by one, after the app has retrieved disk attachments of requested vm. These are quite expensive operations.

Expected results:
Possibility to query for multiple disks by their IDs (obtained from disk_attachments) or to find them by vm ID. 

Additional info:
In 3.6 API this is done by calling /vms/{vmId}/disks, but equivalent feature is missing in 4.0 API.

Comment 1 Filip Krepinsky 2017-01-05 16:47:30 UTC
This feature is not needed for moVirt anymore. 

We fetch all disks instead and then pair them with attachments. Fetching all disks is not problem for us anymore because we need all of them for our dashboard.

Comment 2 Allon Mureinik 2017-01-31 13:33:56 UTC
(In reply to Filip Krepinsky from comment #1)
> This feature is not needed for moVirt anymore. 
> 
> We fetch all disks instead and then pair them with attachments. Fetching all
> disks is not problem for us anymore because we need all of them for our
> dashboard.
Closing for now, feel free to reopen if there's a real usecase behind the request.