Bug 1012378 - Add <display> subtree of <vm> element to response to successful POST /api/vm/UUID/ticket requests
Summary: Add <display> subtree of <vm> element to response to successful POST /api/vm/...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-restapi
Version: 3.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
: 3.4.0
Assignee: Michael Pasternak
QA Contact: Elena
URL:
Whiteboard: virt
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-26 11:29 UTC by David Jaša
Modified: 2014-01-13 01:46 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-10-01 10:36:03 UTC
oVirt Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description David Jaša 2013-09-26 11:29:19 UTC
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:
always

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

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 10:08:57 UTC
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 Program Management 2013-10-01 10:36:03 UTC
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.