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):
Steps to Reproduce:
1. Run edit-node --install <package> on RHEV-H ISO
2. Install modified ISO.
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.
3. The title in the TUI should show modified version or show somehow it was modified.
4. Same for /etc/redhat-release content.
If this is impossible to implement right now, what are the ways to know that the ISO was modified, after it is installed?
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.
I think the grub boot title changes.
Can you please take a look?
The title of the TUI should be changed, because this is visible most of the time.
We shoudl see if this is achievable.
If we could only modify /etc/redhat-release, would be good enough.
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.
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.
Is not the grub line during boot and install process is not enough ?
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.
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.
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.
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?
Fabian, sounds good.
Would I be able providing multiple arguments at the same time?
# edit-node --update=vdsm --comment="fix for rhbz#.."
(In reply to Marina from comment #15)
> Fabian, sounds good.
> Would I be able providing multiple arguments at the same time?
> # edit-node --update=vdsm --comment="fix for rhbz#.."
Yes Marina, should be like that.
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
The title in the TUI is show modified version.
The bug cannot be reproduced, change the status to VERIFIED.
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.