Bug 1012378 - Add <display> subtree of <vm> element to response to successful POST /api/vm/UUID/ticket requests
Add <display> subtree of <vm> element to response to successful POST /api/vm/...
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-restapi (Show other bugs)
Unspecified Unspecified
unspecified Severity low
: ---
: 3.4.0
Assigned To: Michael Pasternak
: Improvement
Depends On:
  Show dependency treegraph
Reported: 2013-09-26 07:29 EDT by David Jaša
Modified: 2014-01-12 20:46 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-10-01 06:36:03 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Jaša 2013-09-26 07:29:19 EDT
Description of problem:
when an REST API app wants to connect to VM console, it needs to:
1) collect running VMs --> GET /api/vms
2) set ticket on selected VM --> POST /api/vms/UUID/ticket
3) get the rest of connection details --> GET /api/vms/UUID
and just now it has all the required info to establish the connection.

Given that:
  * ticket action is almost always preceded or followed with /api/vms/VM request
  * some subset of <vm> information is returned anyway
it would make sense to include <display> subtree in response body to /ticket request in order to save network roundtrips and HTTP/REST requests

Version-Release number of selected component (if applicable):
is16 / rhevm-restapi-3.3.0-0.22.master.el6ev.noarch

How reproducible:

Steps to Reproduce:
1. issue POST request to /api/vms/VM_UUID/ticket

Actual results:
loads of uneeded links are returned but not connection details have to be retrieved in a separate request

Expected results:
all connection details are returned right away

Additional info:
Comment 1 Michael Pasternak 2013-09-29 06:08:57 EDT
while this request makes sense in terms of information consumption, it doesn't
make any in ROA (resource-oriented-architecture) service, 

1. <display> meta is not a part of ticket "resource"
2. <display> content may (potentially) change between action execution and
   actual connect attempt, therefore vm metadata should be always fetched via
   vm representation

-1 for concept.
Comment 2 RHEL Product and Program Management 2013-10-01 06:36:03 EDT
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

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