----- Original Message ----- From: "Juan Hernández" <jhernand(a)redhat.com&gt; 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.

> (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.

> 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.

----- Original Message ----- From: "Frantisek Kobzik" <fkobzik(a)redhat.com&gt; Sent: Thursday, February 19, 2015 10:24:03 AM 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(a)redhat.com&gt; To: "Frantisek Kobzik" <fkobzik(a)redhat.com&gt;, "Juan Hernández" <jhernand(a)redhat.com&gt; Cc: devel(a)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(a)redhat.com&gt; > 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. >