Bug 1304084

Summary: Edit-node should modify the version of the OS, if it modifies the ISO
Product: Red Hat Enterprise Virtualization Manager Reporter: Marina Kalinin <mkalinin>
Component: ovirt-nodeAssignee: Douglas Schilling Landgraf <dougsland>
Status: CLOSED ERRATA QA Contact: Wei Wang <weiwang>
Severity: high Docs Contact:
Priority: low    
Version: 3.5.7CC: dfediuck, fdeutsch, gklein, lsurette, mgoldboi, mkalinin, ycui, ykaul
Target Milestone: ovirt-3.6.9Keywords: ZStream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: rhev-hypervisor7-7.2-20160826.1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-09-26 14:42:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Node RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Marina Kalinin 2016-02-02 20:16:32 UTC
Description of problem:
Today, if you modify RHEV-H ISO with edit-node --install (for example, updating it with vdsm hotfix build), once you install the new ISO, its version would not reflect the change and it will show the same version as an unmodified ISO. This is incorrect. There should be a way to see that this ISO is modified.

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

How reproducible:
Always

Steps to Reproduce:
1. Run edit-node --install <package> on RHEV-H ISO
2. Install modified ISO.


Actual results:
3. RHEVH TUI Title shows same version as before editing it. So no way to know if it is the original version or modified.
4. Same with /etc/redhat-release.

Expected results:
3. The title in the TUI should show modified version or show somehow it was modified.
4. Same for /etc/redhat-release content.

Additional info:
If this is impossible to implement right now, what are the ways to know that the ISO was modified, after it is installed?

Comment 1 Fabian Deutsch 2016-02-03 14:01:18 UTC
Because of compatability to with RHEV-M we can not change the os-release (which is used in the TUI title) right away.

However, we could try adding another mechanism to fix this.

Comment 2 Anatoly Litovsky 2016-04-26 09:12:11 UTC
I think the grub boot title changes.
Can you please take a look?

Comment 3 Fabian Deutsch 2016-05-17 20:09:41 UTC
The title of the TUI should be changed, because this is visible most of the time.
We shoudl see if this is achievable.

Comment 4 Marina Kalinin 2016-05-17 20:54:15 UTC
If we could only modify /etc/redhat-release, would be good enough.

Comment 5 Marina Kalinin 2016-06-17 03:39:54 UTC
Fabian, any reasons not to have it fixed?
Just built another hotfix today and it is annoyingly reporting the original version of the iso.
It is confusing in customers' eyes, after he install the hotfix, but still sees the old version. As well, for GSS representative, when looking into the environment, it is not clear that it runs a hotfix.

Please review and see if can be addressed soon.

Comment 7 Fabian Deutsch 2016-06-17 07:36:30 UTC
The reason is that fixes in the redhat-release area can break logic in the engine side iirc.
We could not rush it into 3.6.7, but we are looking into it for 3.6.8.

Comment 9 Anatoly Litovsky 2016-07-03 11:14:33 UTC
Is not the grub line during boot and install process is not enough ?

Comment 10 Marina Kalinin 2016-07-06 17:31:27 UTC
I do not really care about the grub line. I do, but there are 2 much more important places for me to see it:
- in the database, when I click on the host->software. It should reflect the version. This is how I inspect customer's environment once I get the log collector. 
- in the sos-report from the host. I usually check /etc/redhat-release content. I should not remember going additional places to check that. Not cause I am lazy, cause this is the standard process to check that file.

Comment 12 Fabian Deutsch 2016-07-22 12:58:26 UTC
Marina, this will be very difficult to fix for you.

We could fix the title of the TUI to reflect that the iso was modified.

But we can not fix the version in all other places (Engine, log collector, etc), because in vintage RHEV-H the verison parsing is very sensitive, and we can not mess with it.

If modifying the TUI title is sufficient then we can keep this bug open.

If you need more, then I suppose that we can not deliver it for 3.6.

Comment 13 Marina Kalinin 2016-07-22 13:31:01 UTC
Sure, I understand completely.
It is not a critical issue, but usability for support.
If you can change the title in TUI would be good enough at this point.
Thanks!

Comment 14 Fabian Deutsch 2016-07-26 15:17:02 UTC
Would the foloowing implementation suit your needs:

1. edit-node --comment="fix for rhbz#…"
2. Install node
3. Login to TUI

After 3: The comment will be shown in the TUI Title.

Is this an acceptable solution?

Comment 15 Marina Kalinin 2016-07-26 16:57:59 UTC
Fabian, sounds good.
Would I be able providing multiple arguments at the same time?
Like:
# edit-node --update=vdsm --comment="fix for rhbz#.."

Comment 16 Douglas Schilling Landgraf 2016-07-26 19:39:25 UTC
(In reply to Marina from comment #15)
> Fabian, sounds good.
> Would I be able providing multiple arguments at the same time?
> Like:
> # edit-node --update=vdsm --comment="fix for rhbz#.."

Yes Marina, should be like that.

Comment 17 Wei Wang 2016-09-05 08:48:41 UTC
Test Version:
RHEL7.2
rhev-hypervisor7-7.2-20160826.1.el7ev.noarch.rpm
ovirt-node-tools-3.6.1-15.0.el7ev.noarch.rpm

Test Steps:
1. Install ovirt-node-tools-3.6.1-15.0.el7ev.noarch.rpm with rhel7.2
2. Install rhev-hypervisor7-7.2-20160826.1.el7ev.noarch.rpm with rhel7.2
3. Run command edit-node --nogpgcheck --install vdsm --comment="fix for rhbz#…" --repo /etc/yum.repos.d/test.repo /usr/share/rhev-hypervisor/rhevh-7.2-20160826.1.el7ev.iso
4. Install rhevh-7.2-20160826.1.el7ev-vdsm.iso
5. Check the title of TUI

Result:
The title in the TUI is show modified version.

The bug cannot be reproduced, change the status to VERIFIED.

Comment 19 errata-xmlrpc 2016-09-26 14:42:25 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.

https://rhn.redhat.com/errata/RHEA-2016-1935.html