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" <eco...@redhat.com> To: "Frantisek Kobzik" <fkob...@redhat.com>, "Juan Hernández" <jhern...@redhat.com> Cc: devel@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" <jhern...@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. > _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
