Bug 1264767

enhancement for automation of required version check/setting
see last comments in the original bug below

current thoughts:
- backend able to figure out latest available versions (via yum)
- enforcement "button" somewhere which would set a custom version to check against (pre-filled with the latest)

+++ This bug was initially created as a clone of Bug #1228275 +++

Add support for the remote-viewer's "versions" and "newer-version-url" parameters.

Add 2 new fields to the vdc_options also accessible using engine-config tool:
RemoteViewerSupportedVersions and RemoteViewerNewerVersionUrl.


- RemoteViewerSupportedVersions: list of supported versions for OS. Format:
      <os1>:<minimal version supported1>;<os2>:<minimal version supported2>
      example: linux:3.0;windows:2.5
    
- RemoteViewerNewerVersionUrl: when the version check fals, this url is shown to the user by remote-viewer. It supports the following formats:
      + free text (e.g. http://some.url)
      + ${engine_base_url}: a variable replaced by the url on which engine is running (e.g. http://localhost:8080)
      + ${console_client_resources_url}: replaced by the value of the
        "obrand.common.console_client_resources_url" of the branding resource. If
        defined as absolute path, used. If defined as a relative path, it is
        concatinated with the engine base url.
      + any combination of the above (e.g. ${engine_base_url}/my/custom/address)

--- Additional comment from Max Kovgan on 2015-06-28 16:13:33 CEST ---

ovirt-3.6.0-3 release

--- Additional comment from sefi litmanovich on 2015-07-30 10:11:53 CEST ---

Verified with ovirt-engine-3.6.0-0.0.master.20150726172446.git65db93d.el6.noarch according to attached polarion test plan.

https://polarion.engineering.redhat.com/polarion/#/project/RHEVM3/testrun?id=3_6_VIRT_Spice_Client_Version_Requirement_2907

Tests on windows client not performed due to unsporting remote-viewer version for windows.

--- Additional comment from David Jaša on 2015-09-12 00:47:21 CEST ---

I went through the test run and I'm not sure if this we can declare this as implemented/VERIFIED.

The problem is that in all cases, manual update of RemoteViewerSupportedVersions is necessary after each remote viewer version availability in order to trigger the client updates. This is regression from activex's fully automatic updates of all the clients after the update of client available in the engine.

IMO the RemoteViewerSupportedVersions should be set to some special value indicating that the latest versions hosted by the engine instance should be filled by default (e.g. RemoteViewerSupportedVersions=${available_on_engine} for downstream) so that by default, all clients are updated whenever an update is available. The possibility of setting RemoteViewerSupportedVersions to something else should be enough to control the update time in deployments whose administrators wish to do so.

Upsteam could have a different value that would make engine check the upsteam site in some time interval (e.g. daily) and fill that version in .vv file.

--- Additional comment from Michal Skrivanek on 2015-09-17 16:41:11 CEST ---

That it is perhaps not what we want it to be, that's a separate issue:)
Unfortunately not an easy one to solve. let me elaborate

For Linux we do not have any knowledge of the latest available version. We can perhaps monitor something...when, every day, every week, poll spice-space.org? check RHEL channels? What if they are different on the client

For Windows this is a bit more simple, we only have one build on all Windows and we deliver it (downstream) from the engine host...so we know what is the latest version. But not quite without effort, the current version we can "see" is of SPICE, whereas the application is remote viewer...a different "string" whcih is opaque to us. So not helpful. And upstream we would either have to deliver the client the same way as downstream, or poll some well-known place the same way as for Linux

TL;DR - it deserves a new feature bug and cooperation between multiple teams

the bug is implemented according to description, so I'm moving it back