Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1552194 - Update name of RHEV-toolsSetup* ISO to attach in search algorithm
Summary: Update name of RHEV-toolsSetup* ISO to attach in search algorithm
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: rhevm-setup-plugins
Version: 4.2.2
Hardware: Unspecified
OS: Unspecified
Target Milestone: ovirt-4.2.3
: ---
Assignee: Lev Veyde
QA Contact: Vitalii Yerys
Depends On:
Blocks: 1550947
TreeView+ depends on / blocked
Reported: 2018-03-06 16:34 UTC by Radek Duda
Modified: 2018-05-15 17:35 UTC (History)
11 users (show)

Fixed In Version: rhvm-setup-plugins-4.2.6-1.el7ev
Doc Type: No Doc Update
Doc Text:
The engine now correctly identifies toolsSetup ISO files with both the old and new naming conventions (RHEV-toolsSetup.iso and RHEV-toolsSetup.iso) and tries to use the latest first.
Clone Of:
Last Closed: 2018-05-15 17:34:27 UTC
oVirt Team: Virt
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2018:1473 None None None 2018-05-15 17:35:31 UTC
oVirt gerrit 88708 master MERGED packaging: setup: Use real ISO name instead of the link 2018-04-18 06:04:19 UTC
oVirt gerrit 90432 ovirt-engine-4.2 MERGED packaging: setup: Use real ISO name instead of the link 2018-04-18 07:20:35 UTC

Description Radek Duda 2018-03-06 16:34:03 UTC
Description of problem:
RHEV-toolsSetup*.iso has been recently renamed to RHV-toolsSetup*.iso. VM of Windows OS type automatically attaches latest RHEV-toolsSetup*.iso upon start. The name of iso to attach should be now updated to RHV-toolsSetup*.iso, so that if no RHV-toolsSetup*.iso is found then it searches for older RHEV-toolsSetup*.iso

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

How reproducible:

Steps to Reproduce:
1. have both new RHV-toolsSetup*.iso and older RHEV-toolsSetup*.iso in ISO domain
2.start VM of 'Operating system'=Windows* type

Actual results:
attached CD to VM is latest RHEV-toolsSetup*.iso

Expected results:
attached CD to VM is latest RHV-toolsSetup*.iso

Additional info:

Comment 1 Michal Skrivanek 2018-03-08 12:22:56 UTC
when exactly does it attach that CD automatically for you? do you have an example?

Comment 2 Radek Duda 2018-03-08 13:23:28 UTC
The CD is attached in the case that any RHEV-toolsSetup*.iso is found in ISO domain, VM is of Windows* type (choose 'Operatin System' = Windows* in VM editor) . I have both RHEV-toolsSetup*.iso and RHV-toolsSetup*.iso and it attaches the older ISO.

Comment 3 Michal Skrivanek 2018-03-08 13:27:56 UTC
right, but per current doc (which is wrong, IMO) you're supposed to upload rhev-guest-tools.iso.
I expect that in that case the feature of automatically updating guest tools do not actually work. For a looong time, so apparently we do not have a test case for that!

Comment 4 Michal Skrivanek 2018-03-08 13:31:14 UTC
Lev, this seem to be broken for a long time. What would it take to fix that functionality? Can you please summarize how the tools iso is named, how does the service show up in windows, etc? there's a lot of legacy code in engine which would supposedly still work if things are named right (or update those places to current state)


Comment 5 Lev Veyde 2018-03-08 17:45:02 UTC
The main issue is that we basically used the link to upload the ISO into the ISO domain. That caused the ISO to be always named rhev-tools-setup.iso (or rhv-tools-setup.iso in RHV 4.2).

The full filename of the ISO is coded as RHEV-toolsSetup_X.Y_Z.iso (or RHV-toolsSetup_4.2_Z.iso in case of RHV 4.2), where X.Y is the RHEV/RHEV version e.g. 4.1 and Z is the tools release number e.g. 2.

Comment 6 Yedidyah Bar David 2018-03-11 06:59:11 UTC
Please note that using engine-setup to create a local NFS ISO domain is deprecated, see bug 1332813, and considered harmful if the engine is a self-hosted-engine.

Also, in 4.2, there were several relevant changes in the engine itself, including how to upload and use ISO images. IMO if we want to keep the functionality discussed in this bug, it should be re-implemented from scratch, probably on the engine (not engine-setup), or even in a new tool packaged with the iso image itself. A possible sketch of how this should work: If the engine notices (or is told) that a new iso image is available/installed, it will show some icon/notification/etc in the admin ui, and/or notify using the notifier service. If/when the user then chooses to, the engine will let the user pick a storage domain to upload the iso to (or use a default one if we decide we want a default, or if there is only one, use that, etc), and upload the image there.

Allon - makes sense? If so, please take care (open RFEs etc). Thanks.

Current bug, if we decide to fix at all, probably applies only to systems upgraded from earlier versions, which did allow creating an ISO domain by engine-setup.

Comment 7 Allon Mureinik 2018-03-11 08:34:17 UTC
Tal, you're leading the ISO effort - what's your take on this?

Comment 8 Tal Nisan 2018-03-12 13:14:06 UTC
This should definitely be written from scratch taking into consideration the ISO on data domains RFE and the future deprecation of the ISO domain.
Didi, I'm not sure I know all the fine details here, let's give it a bit of a more detailed design and go on from there

Comment 9 Yedidyah Bar David 2018-03-12 13:42:36 UTC
OK, filed for now bug 1554339.

Comment 10 Michal Skrivanek 2018-03-28 07:42:56 UTC
still the bug is relevant - if you name the iso correctly (comment #5) the auto update would work, supposing it would still be on ISO domain. It's also wrong in documentation. 
For ISOs on data domains...I do not know how those look ups work in other flows.

Comment 11 Yaniv Kaul 2018-04-11 10:27:09 UTC
What's the latest status here? It seems to be stuck on POST on a patch that hasn't moved for a while?

Comment 12 Lev Veyde 2018-04-11 13:34:22 UTC
(In reply to Yaniv Kaul from comment #11)
> What's the latest status here? It seems to be stuck on POST on a patch that
> hasn't moved for a while?

I think that we're ready to merge the patches and backport them to 4.2.

Will try to push the merge process.

Comment 14 Vitalii Yerys 2018-04-26 18:02:45 UTC
Verified on

RHV-WGT-4.2-5 was attached, while both RHV-*-4.2-5 and RHEV-*-4.2-5 were available on the ISO domain

Comment 17 errata-xmlrpc 2018-05-15 17:34:27 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

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