Hi,
This is about the changes introduced by patch
http://gerrit.ovirt.org/#/c/35281 (restapi: adjust api to new
graphics representation).
There are a couple of issues with the VM's display type value:
(1) the "display -> type" value of the VM in the REST API seem to
map to different properties based on the VM status.
see
http://i.imgur.com/Mn1RITW.png:
When the VM is Up, the "display -> type" value in the REST API
matches the 'Display' value in the GUI.
But when the VM is Down, the "display -> type" value in the REST
API matches the 'Graphics Protocol' value in the GUI and does not
necessarily match the 'Display' value (e.g. in case we invoked
'Run Once' on the VM with a different Console value).
Is there a reason for the values in the REST API to not match the
ones in the GUI? it's a bit confusing.
Maybe need to have two properties in the REST API to match the two
displayed values in the GUI: 'Display' (which, IIUC, is the 'run-
time' value) and 'Graphics Protocol' (which, IIUC, is the
'configured'/persisted value)?
I understand that there may be backward-compatibility issues with
naming/terminology, but perhaps we can come up with a solution that
will not break the backward compatibility?
(2) in patch
http://gerrit.ovirt.org/#/c/35281, it seems that the
REST API is calling a query *per VM* in order to re-populate the
display-related values.
This will potentially overload the engine, especially if we are
planning to move the GUI to work over the REST API and request
VMs every 5 seconds (by default) per client, as we are doing today.
Are there any plans to optimize this behavior (e.g. populate the
correct display-related values on the db-side, rather than re-
populating them on the REST-API side using a per-VM query)?
Many thanks in advance.
----
Regards,
Einav