[ovirt-devel] Issues with the VM display type value(s)

[Frantisek Kobzik]

Hi,

sorry for late response, I was on something else. I'll explore that problem ASAP. I'll have to start working on the new graphics/display representation in restapi anyway so I'll try to solve this nasty behavior as well.

Cheers!
Franta.


----- Original Message -----
From: "Einav Cohen" <ecohen at redhat.com>
To: "Frantisek Kobzik" <fkobzik at redhat.com>, "Juan Hernández" <jhernand at redhat.com>
Cc: devel at ovirt.org
Sent: Thursday, February 19, 2015 2:47:21 PM
Subject: Re: [ovirt-devel] Issues with the VM display type value(s)

> ----- Original Message -----
> From: "Juan Hernández" <jhernand at redhat.com>
> Sent: Thursday, February 19, 2015 5:44:42 AM
> 
> On 02/18/2015 11:10 PM, Einav Cohen wrote:
> > 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?
> > 
> 
> This behavior wasn't introduced by that patch, rather the patch was
> carefully crafted to preserve it, for backwards compatibility.
> 
> My understanding is that the virt team plans to do larger changes to
> this area of the RESTAPI to reflect the new separation of the "video
> device" and "graphics device" concepts. I think that your concerns can
> be handled in the context of those larger changes.

I opened the following BZ:
Bug 1194287 - VM display type in REST API doesn't have 1:1 match with GUI
[https://bugzilla.redhat.com/show_bug.cgi?id=1194287]

virt: If there are plans to refactor the entire VM-display area in the code, 
feel free to block this BZ on the relevant refactor BZ / close this BZ as 
duplicate / ...

> 
> > (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)?
> > 
> 
> Currently there are no plans to change this because the backend doesn't
> have a mechanism to provide all the related display information using
> only one query. I'd suggest to implement at least a query that takes
> multiple VM identifiers and returns the graphics devices of those
> multiple VMs. This would allow for a 1+1 queries scenario, instead of
> 1+N. Once the backend provides this the RESTAPI can be changed to use
> it. This is for the virt team to decide, I'd suggest you open a bug.

I opened the following bug:
Bug 1194291 - REST API is calling a query _per VM_ in order to re-populate the display-related values -> potential engine overload
[https://bugzilla.redhat.com/show_bug.cgi?id=1194291]

Thanks. 

> 
> > Many thanks in advance.
> > 
> > ----
> > Regards,
> > Einav
> 
> --
> Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> 3ºD, 28016 Madrid, Spain
> Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
>