Hide Forgot
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
Do we want to do that finally? At least some reasonable baseline from e.g. a previous release.
we'll need a validation from spice QE regarding the tested version to be configured as minimal.
Just keep in mind that the minimal version has to be the one which supports the new authentication introduced in 4.0
the minimal version will be set like this: rhev-win64:2.0-128;rhev-win32:2.0-128;rhel7:2.0-6;rhel6:2.0-14
Verified with rhevm-4.0.0.6-0.1.el7ev. Scope of this RFE and of this test is the two attached test cases which check that the specific minimal version values are enforced in DB and are injected properly to .vv file. Further test will be held in scope of attached test plan. There might be a bug on spice scope where I was able to open a console with version lower than enforced minimal version on a windows 7 32 bit client with virt-viewer-x86-2.0.msi, I am checking this with spice team and opening a bug if it is in fact one.
oVirt 4.0.0 has been released, closing current release.