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.
isn't this just downgrading the rpm back to the working version on the engine?
(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?
(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?
(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.
As we move to MSI + MIME deployment this can be handled by administrators cleanly in a way that we can't with AX + XPI
(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?
It'd just be an MSI so could be hosted anywhere, even emailed.