Bug 1463633 - [RFE] Provide support for data aggregation when fetching entities
[RFE] Provide support for data aggregation when fetching entities
Status: CLOSED CURRENTRELEASE
Product: ovirt-engine
Classification: oVirt
Component: RestAPI (Show other bugs)
4.1.3.3
Unspecified Unspecified
high Severity high (vote)
: ovirt-4.2.0
: 4.2.0
Assigned To: Ori Liel
samuel macko
: FutureFeature
Depends On:
Blocks: 1436206
  Show dependency treegraph
 
Reported: 2017-06-21 07:35 EDT by Martin Perina
Modified: 2017-12-20 06:06 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
This update enables Red Hat Virtualization API users to request that contents of some of the entity's links be returned inline, inside the requested entity. Previously, to retrieve multiple related objects from the API, the only alternative was to retrieve the first one, then send additional requests to retrieve the related objects. For example, if you needed a virtual machine and also the disks and NICs, you would need to first send a request like this: GET /ovirt-engine/api/vms/123 And then send additional requests to get the disk attachments, the disks, and the NICs: GET /ovirt-engine/api/vms/123/diskattachments GET /ovirt-engine/api/disks/456 GET /ovirt-engine/api/disks/789 GET /ovirt-engine/api/vms/123/nics In environments with high latency, this increases the time required to retrieve the data. In addition, it also means that multiple queries have to be sent to the database to retrieve the data. To improve this, a new follow parameter has been introduced. This parameter is a list of links that the server should follow and populate. For example, the previous scenario will be solved sending this request: GET /ovirt-engine/api/vms/123?follow=diskattachments.disks,nics This will return the virtual machine with the disks and the NICs embedded in the same response, thus avoiding the multiple network round-trips. The multiple database queries will be avoided only if the server is modified to retrieve that data with the more efficient queries, otherwise the server will use the approach of calling itself to retrieve it, which won’t improve the number of queries.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-12-20 06:06:58 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑4.2+
lsvaty: testing_plan_complete-
mgoldboi: planning_ack+
mperina: devel_ack+
lsvaty: testing_ack+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 77793 master MERGED Generate doGet, doList methods 2017-07-03 04:56 EDT
oVirt gerrit 79993 None None None 2017-08-03 12:48 EDT

  None (edit)
Description Martin Perina 2017-06-21 07:35:08 EDT
Description of problem:

Currently when someone wants to fetch resources (for example VMs) using RESTAPI, he will need additional requests to fetch also its sub resources (like NICs or disk attachments). But inside RESTAPI we already return links to those subresources, so it would not be hard to provide parameter 'follow' to define which subresources should be fetched along with main resource using single request, for example:

  GET /ovirt-engine/api/vms?follow="nics,disk_attachments"

RESTAPI will also provide default "naive" subresource fetching (which of course is not optimized for performance), but we will provide infrastructure for engine developers to easily add performance optimized implementations for common use cases (for example BZ1436206)

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 3 samuel macko 2017-08-24 10:40:02 EDT
Verified in ovirt version 4.2.0-0.0.master.20170823165744.git116f435.el7.centos

Tested with:
  GET /ovirt-engine/api/vms?follow=disk_attachments,nics

Result:
<vms>
 <vm>
  <disk_attachments>
  </disk_attachments>
  ...
  <nics>
  </nics>
 </vm>
</vms>
Comment 5 Sandro Bonazzola 2017-12-20 06:06:58 EST
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017.

Since the problem described in this bug report should be
resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.

Note You need to log in before you can comment on or make changes to this bug.