Bug 963501 - [RFE] ability to select version of virt-viewer to deploy to clients
[RFE] ability to select version of virt-viewer to deploy to clients
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: spice-activex-win (Show other bugs)
3.1.3
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Arnon Gilboa
Desktop QE
virt
: FutureFeature, Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-15 21:21 EDT by Bryan Yount
Modified: 2015-09-22 09 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-18 08:14:20 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 374273 None None None Never

  None (edit)
Description Bryan Yount 2013-05-15 21:21:06 EDT
Description of problem:
The customer needs the ability to select the version of virt-viewer that they are able to deploy to their clients. The example presented by the customer is "What if a new virt-viewer is released and we discover a regression in the newest version. We need the ability to push the previous release out to our clients without having to edit the SpiceVersion.txt file."

Version-Release number of selected component (if applicable):
RHEV 3.1.3

Steps to Reproduce:
1. Run yum update rhevm-spice-client* on the RHEVM system
2. Connect to a Spice console from a Windows client machine
3. New version of virt-viewer is pushed out to the client
4. An issue is discovered that requires a roll-back to the previous virt-viewer
  
Actual results:
A manual process of downgrading the rhevm-spice-client* packages and hand-editing the /usr/share/spice/SpiceVersion*.txt to increment the build number to 1 integer higher than the latest version that was pushed out to clients

Expected results:
Ability in the AdminPortal to select which version "Current" or "Previous" to deploy to clients

Additional info:
There should be a better method for pushing out new Spice clients to Windows users that allows for some version flexibility.
Comment 2 Itamar Heim 2013-05-17 03:10:41 EDT
isn't this just downgrading the rpm back to the working version on the engine?
Comment 3 Lee Yarwood 2013-05-29 10:47:44 EDT
(In reply to Itamar Heim from comment #2)
> isn't this just downgrading the rpm back to the working version on the
> engine?

I can see Bryan documented this in the attached kbase but I think the customer behind the now closed case that prompted this RFE wanted a more automatic solution. Bryan can you confirm?
Comment 4 Itamar Heim 2013-05-29 11:14:46 EDT
(In reply to Lee Yarwood from comment #3)
> (In reply to Itamar Heim from comment #2)
> > isn't this just downgrading the rpm back to the working version on the
> > engine?
> 
> I can see Bryan documented this in the attached kbase but I think the
> customer behind the now closed case that prompted this RFE wanted a more
> automatic solution. Bryan can you confirm?

we can't do automatic things from engine about rpm's being deployed at system level?
Comment 5 Bryan Yount 2013-05-29 13:54:12 EDT
(In reply to Itamar Heim from comment #2)
> isn't this just downgrading the rpm back to the working version on the
> engine?

Yes, for most Linux admins this would be an easy downgrade of the RPM but there's also the issue of manually editing the SpiceVersion.txt file to make the version number 1 higher than it was before so that you trick IE into thinking there's an update when it's really a downgrade.

(In reply to Lee Yarwood from comment #3)
> I can see Bryan documented this in the attached kbase but I think the
> customer behind the now closed case that prompted this RFE wanted a more
> automatic solution. Bryan can you confirm?

Lee, that is correct. The idea here is we're selling RHEV to people that aren't necessarily Linux-savvy and it would be good if we could make the product as friendly and easy to use as possible. This would help the novice admin roll back a version of virt-viewer if the latest one, for example, started crashing on all their client machines or something.
Comment 7 Andrew Cathrow 2013-07-08 10:57:36 EDT
As we move to MSI + MIME deployment this can be handled by administrators cleanly in a way that we can't with AX + XPI
Comment 8 Bryan Yount 2013-07-17 20:35:31 EDT
(In reply to Andrew Cathrow from comment #7)
> As we move to MSI + MIME deployment this can be handled by administrators
> cleanly in a way that we can't with AX + XPI

I have a question for you, though, Andy. What about my customer where most of their users are outside the environment and not under the company's control? How will the spice-client be distributed then? Will it still be hosted on the RHEV-M?
Comment 9 Andrew Cathrow 2013-07-18 08:14:20 EDT
It'd just be an MSI so could be hosted anywhere, even emailed.

Note You need to log in before you can comment on or make changes to this bug.