Bug 1012378

Summary:	Add <display> subtree of <vm> element to response to successful POST /api/vm/UUID/ticket requests
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	David Jaša <djasa>
Component:	ovirt-engine-restapi	Assignee:	Michael Pasternak <mpastern>
Status:	CLOSED WONTFIX	QA Contact:	Elena <edolinin>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	3.3.0	CC:	acathrow, bazulay, iheim, michal.skrivanek, mpastern, oramraz, Rhev-m-bugs, srevivo, yeylon
Target Milestone:	---	Keywords:	Improvement
Target Release:	3.4.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	virt
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-10-01 10:36:03 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

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.