Bug 1489567 - Host Software tab does not show exact RHVH version anymore
Summary: Host Software tab does not show exact RHVH version anymore
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-node-ng
Version: 4.1.5
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ovirt-4.2.0
: ---
Assignee: Ryan Barry
QA Contact: cshao
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-07 18:34 UTC by Marina Kalinin
Modified: 2019-05-16 13:05 UTC (History)
22 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Red Hat Virtualization Manager now displays the Red Hat Virtualization Host version installed.
Clone Of:
Environment:
Last Closed: 2018-05-15 17:57:40 UTC
oVirt Team: Node
Target Upstream Version:
rbarry: needinfo-
rbarry: needinfo-


Attachments (Terms of Use)
RHEVH Version in UI - RHEV 3.6 (and any previous 3.x versions) (57.68 KB, image/png)
2017-09-26 19:58 UTC, Marina Kalinin
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:1524 0 None None None 2018-05-15 17:58:49 UTC

Description Marina Kalinin 2017-09-07 18:34:02 UTC
Description of problem:
In the past, hosts' software bottom pane was always showing the correct version of the hypervisor, i.e.:
redhat-virtualization-host-image-update-4.1-20170808.0.el7_4
redhat-virtualization-host-image-update-4.1-20170706.0.el7_3

Now it shows some weird text that does not provide clear and unique information for identifying the actual version used. Like:
OS Version:     RHEL - 7.3 - 2.2.el7
OS Description: Red Hat Virtualization Host 4.1 (el7.3)

To fix this bug either show the actual image version or provide a clear and obvious way to correlate from the current text to the actual version.

Comment 1 Marina Kalinin 2017-09-07 18:36:37 UTC
Need to grab PRETTY_NAME from the host to present this info correctly.

Comment 2 Ryan Barry 2017-09-07 18:36:58 UTC
This can be retrieved with rpm (if we want the exact version), or the version/release of redhat-release-virtualization-host if we want to present "Red Hat Virtualization Host 4.1.X (el7.Y)"

We can add this to PRETTY_NAME if it makes it easier for you

Comment 5 Martin Perina 2017-09-08 12:48:02 UTC
(In reply to Marina from comment #0)
> Description of problem:
> In the past, hosts' software bottom pane was always showing the correct
> version of the hypervisor, i.e.:
> redhat-virtualization-host-image-update-4.1-20170808.0.el7_4
> redhat-virtualization-host-image-update-4.1-20170706.0.el7_3
> 
> Now it shows some weird text that does not provide clear and unique
> information for identifying the actual version used. Like:
> OS Version:     RHEL - 7.3 - 2.2.el7
> OS Description: Red Hat Virtualization Host 4.1 (el7.3)
> 
> To fix this bug either show the actual image version or provide a clear and
> obvious way to correlate from the current text to the actual version.

OS Description shows the value of PRETTY_NAME from /etc/os-release, OS Version should show the version of RHEL (for RHEL-H) or underlying RHEL (for RHV-H). Both fields behave the same way since 4.0

Comment 6 Ryan Barry 2017-09-26 09:05:54 UTC
Marina, are you sure we used to report this?

Comment 7 Marina Kalinin 2017-09-26 19:58:53 UTC
Created attachment 1331227 [details]
RHEVH Version in UI - RHEV 3.6 (and any previous 3.x versions)

Comment 8 Ryan Barry 2017-09-26 23:14:11 UTC
Judging from the posted screenshot, this is vintage RHVH.

The requested information has not been available in any version of NGN. This is something which could theoretically be added by the engine team by looking at /usr/share/imgbased/meta/nvr.

Or we could add another field to /etc/os-release, but that would require an additional field in RHVM for NGN nodes only.

Moving back to Infra for evaluation, though we'll also want input from PM.

Comment 9 Marina Kalinin 2017-09-27 20:13:01 UTC
Ryan and all, the fact that it is not available on NGN, does not mean it should not work this way. NGN is replacing vintage RHEVH and it should provide the same functionality.

There is a lot of detailed information there already. And it is good and useful. I do not understand why not to present the most useful information about the actual version of the host installed? 

How else can I / user / admin know what they are running if they don't have exact version number in their view?? Currently provided information does not seem to be useful at all:

RHEL - 7.4 - 5.0.el7
Red Hat Virtualization Host 4.1 (el7.4)

Ok, how do I find the relevant one from the available list?
https://access.redhat.com/downloads/content/150/ver=4.1/rhel---7/4.1/x86_64/product-software

Comment 10 Ryan Barry 2017-09-27 20:55:40 UTC
Logging into the host, unfortunately. Console or cockpit.

This was an intentional design decision in NGN (cockpit and dracut also use PRETTY_NAME), and there was a specific request to show the underlying RHEL version.

Changing PRETTY_NAME will break ovirt-host-deploy on NGN. Really needs input from the engine team and vdsm teams for their willingness to take on additional metric gathering on RHVH.

See also: https://bugzilla.redhat.com/show_bug.cgi?id=1368364

And https://github.com/oVirt/vdsm/blob/master/lib/vdsm/osinfo.py

Getting vdsm osinfo to get the "right" information from imgbased/meta/nvr would be easy, but it needs PM input

Comment 11 Allie DeVolder 2017-09-28 21:09:30 UTC
From a support perspective, it's vital that we and customers are easily able to tell exactly what version of RHV-H/RHEV-H/RHEL+vdsm that is implemented on a host from the standard location: /etc/redhat-release.

As it stands, for each case involving RHV-4.x hypervisors of any kind, it's taking up valuable time either explaining to the customer how to tell us what exactly they need to do to give us the information we need, when there's already a standard procedure and location for this: `cat /etc/redhat-release`

Comment 12 Ryan Barry 2017-09-28 21:51:59 UTC
Appreciated, however, /etc/redhat-release is _not_ a standard location to find out what software is installed on the system, on 4.x RHVH hosts or RHEL-H hosts.

For RHVH hosts after 4.x, exactly the same steps are used to determine the RHEL version and vdsm version -- the "Software" tab in RHVM.

This also pulls the version of SPICE, Ceph, and other software from the RPM database. In that sense, it would be better for the "Software" tab to also show imgbased/meta/nvr or 'rpm -q redhat-release-virtualization-host-image-update' (though this is not available on fresh installs, hence imgbased/meta/nvr)

Wedging this information into /etc/redhat-release is not an appropriate solution, IMO.

If the customer needed to find out the version of openssl, glibc, or anything else, they would need to log into the system to check the RPM database. On RHVH, logging into and checking 'imgbase w' to find the exact version is no different.

I'm not opposed to this request, but it is not a RHVH bug, and should be handled by Engine. We'll provide whatever is necessary to make this easier.

Comment 13 Martin Tessun 2017-10-04 14:18:29 UTC
Couldn't RHV-H/engine just query for the RHVH image packages and display the installed version in the Web-UI?

This seems quite easily achievable from my PoV.

Comment 14 Martin Perina 2017-10-04 19:41:26 UTC
(In reply to Martin Tessun from comment #13)
> Couldn't RHV-H/engine just query for the RHVH image packages and display the
> installed version in the Web-UI?
> 
> This seems quite easily achievable from my PoV.

I don't like that idea, because it would require additional (and maybe even periodical) request from engine to host.

In RHV 4.0 we have introduced parsing of pretty name (from /etc/os-release) on VDSM which is currently shown as OS Description in Host detail in webadmin. And pretty name (OS Description) was introduced exactly to known which RHVH version is installed on the host. 

So if some vital information about RHVH version are missing, it should be added to the pretty name in /etc/os-release. Also OS Description is used only for displaying and it's not parsed inside engine (unlike OS version which is parsed and used), so there is no harm adding additional info into it.

Comment 15 Ryan Barry 2017-10-04 19:50:21 UTC
Any change we make to os-release potentially affects platform software. The only "safe" field here is PRETTY_NAME, which also affects branding in Dracut and Cockpit.

The engine already requests (through vdsm) a number of queries to the RPM database. A partial list is in comment#12 

Is there a good reason why Engine can't also do this for Node or systems with the appropriate vds_type? I don't imagine Engine is repeatedly querying the version of libvirt, for example.

Even if this is not available as part of the "OS Description" and is under "Host Details", at least it's available.

This cannot be solved by Node anywhere in os-release without significant side effects and possible hard-to-catch regressions in platform packages, and querying the rpmdb is significantly more expensive than the bare output of a single one-line file, but we already do that in Engine.

I don't want to reassign back repeatedly, but we cannot fix this. It must be engine. Again, we're happy to provide the information where possible (which cannot be PRETTY_NAME), so what's needed to move this forward from Engine?

Comment 16 Martin Perina 2017-10-05 09:37:10 UTC
I still don't understand why concrete version cannot be part of PRETTY_NAME, currently there is something like:

  Red Hat Virtualization Host 4.1 (el7.3)

So why is so hard to add z-stream into already provided version?

  Red Hat Virtualization Host 4.1.7 (el7.3)
  Red Hat Virtualization Host 4.1.7.1 (el7.3)

IMO just having z-stream (or z-stream minor if needed) should be enough for customers to know that they are using most up-to-date RHVH (not to mention that we check for possible upgrades and issue audit log message for possible upgrade for each host).

Anyway if above is really not possible then 2 alternate options came to my mind:

 1. Inside VDSM when we fetch PRETTY_NAME from /etc/os-release we could append specific ovirt-node-ng-image-update version, for example:

     Red Hat Virtualization Host 4.1 (el7.4): 4.1-20171130.0.el7_4

    - It's hacky, because we will need to add conditional to VDSM code to perform that only for NGN
    - It will work only on 4.2 NGN (maybe 4.1.z if we decide to backport),
      but advantage is that it will be displayed in all 4.x engines

2. Add another field to getCaps to report ovirt-node-ng-image-update version

    - As I said above, I don't see reason why we need 3 fields to display correct host version (OS Version, OS Description and the new one)
    - It will require changes on both VDSM and engine
    - Even if 4.2 VDSM with this change will be added into 4.0/4.1 engine, this won't be visible, unless engine part is also backported


So from my point of view:

  1. Adding z-stream version to PRETTY_NAME - correct solution for this (this is the reason why we added PRETTY_NAME reporting in 4.0)
  2. Appending version to PRETTY_NAME in VDSM - hack, but if agreed possible to backport to 4.1.z
  3. Adding new field to getCaps - RFE for 4.2 (and that's risky as we have only a few weeks before feature freeze)

Comment 17 Ryan Barry 2017-10-05 17:37:13 UTC
To be clear, we definitely can add z-stream into the PRETTY_NAME. It isn't difficult to change that 

However, I don't think this is what the request is asking for. The exact version would lead to something like:

Red Hat Virtualization Host 4.1-20170924.0 (el7.3) or similar, which is ugly, for lack of a better term. If having the Z-stream version in PRETTY_NAME works for Marina, it works for me, and this is easy to implement. The exact version would be harder to implment (not impossible) -- but I'm opposed mostly because it would look very bad in cockpit/dracut.

I would suggest, as above, querying /usr/share/imgbased/meta/nvr to get the exact version, and showing this under "Host Details" alongside ceph/libvirt/gluster/etc.

This should be easy to implement from vdsm, won't require any concatenation, etc.

From a vdsm point of view, this should be as easy as a simple conditional:

if os.path.exists("/usr/share/imgbased/meta/nvr"):
  node_version = open("/usr/share/imgbased/meta/nvr").read()

Then adding it to whatever dict is returned.

I'm not sure how the parsing looks from the engine side, but I'd imagine adding another entity from a HashMap (or whatever the structure is) should not be terrible, and is hopefully not dependent on the vds_type

Marina -- is the Z-stream in os-release ok, or do you really need the exact version?

Comment 18 Marina Kalinin 2017-10-05 21:13:39 UTC
(In reply to Ryan Barry from comment #17)
> To be clear, we definitely can add z-stream into the PRETTY_NAME. It isn't
> difficult to change that 
> 
> However, I don't think this is what the request is asking for. The exact
> version would lead to something like:
> 
> Red Hat Virtualization Host 4.1-20170924.0 (el7.3) or similar, which is
> ugly, for lack of a better term. If having the Z-stream version in
> PRETTY_NAME works for Marina, it works for me, and this is easy to
> implement. The exact version would be harder to implment (not impossible) --
> but I'm opposed mostly because it would look very bad in cockpit/dracut.
I don't think this is ugly. I think it is reasonable and exact.
> 
> I would suggest, as above, querying /usr/share/imgbased/meta/nvr to get the
> exact version, and showing this under "Host Details" alongside
> ceph/libvirt/gluster/etc.
> 
> This should be easy to implement from vdsm, won't require any concatenation,
> etc.
> 
> From a vdsm point of view, this should be as easy as a simple conditional:
> 
> if os.path.exists("/usr/share/imgbased/meta/nvr"):
>   node_version = open("/usr/share/imgbased/meta/nvr").read()
> 
> Then adding it to whatever dict is returned.
> 
> I'm not sure how the parsing looks from the engine side, but I'd imagine
> adding another entity from a HashMap (or whatever the structure is) should
> not be terrible, and is hopefully not dependent on the vds_type
> 
> Marina -- is the Z-stream in os-release ok, or do you really need the exact
> version?
I cannot disagree with you. This makes even more sense.
So: would it be what: 4.1.6? 4.17? What if it is async?
can you please give more examples? But basically I think it should be fine, as long as I can easily identify the exact version the customer is running at each moment from the administrative portal of the management tool (RHV Admin Portal, I mean).

Comment 19 Ryan Barry 2017-10-05 22:10:49 UTC
Async are generally successively named -1, -2, etc.

So it would be something like:

4.1.3
4.1.4
4.1.4-1
4.1.5
4.1.6
4.1.6-1
4.1.6-2

etc

Comment 20 dguo 2017-10-10 06:48:37 UTC
While getting host software info from latest build: 

OS Version: RHEL - 7.4 - 6.0.el7
OS Description: Red Hat Virtualization Host 4.1 (el7.4)

QE can ack+ about this bug.

Comment 21 Martin Tessun 2017-10-10 11:39:04 UTC
Marina,

could you please give final "blessing" for the proposal in comment #19?

Just keep in mind that typically our ISOs in the portal are not named that way, but more like stated in comment #17

So personally, I think that querying nvr is the most sensible one (and as I understood from Ryan would be a textfile and is not yet available).

Thanks!
Martin

Comment 22 Ryan Barry 2017-10-10 11:43:08 UTC
Just to note — the nvr textfile has been available since the initial release of NGN, so it's usable now. We use this to determine what the LVs should be named

Comment 23 Marina Kalinin 2017-10-10 13:08:12 UTC
Since we have package manifest now, and it goes by z-stream versions, I think comment#19 works and this way everything should be aligned well:
https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html/package_manifest/

Comment 29 Yaniv Kaul 2017-11-16 08:04:05 UTC
Can the bug move to MODIFIED?

Comment 31 dguo 2017-12-11 08:18:17 UTC
Test versions:
rhvh-4.2.0.5-0.20171207.0+1
rhvm-4.2.0-0.5.master.el7
vdsm-4.20.9-1.el7ev.x86_64

Test steps:
1. Install latest redhat-virtualization-host-4.2-20171207.1
2. Add rhvh to rhvm
3. Check software info of rhvh on the rhvm

Test results:
1. After step #3,
OS Version:
RHEL - 7.4 - 0.5.el7
OS Description:
Red Hat Virtualization Host 4.2.0 (el7.4)

Based on above result, z stream version(4.2.0) can be shown on software info, changed this bug to verified.

Comment 34 cshao 2018-04-24 03:35:04 UTC
Test versions:
redhat-virtualization-host-4.2-20180420.0 
rhvm-4.2.3.2-0.1.el7
vdsm-4.20.26-1.el7ev.x86_64

Test steps:
1. Install redhat-virtualization-host-4.2-20180420.0 via iso.
2. Add rhvh to rhvm
3. Check software info of rhvh on the rhvm

Test results:
1. After step #3,
OS Version:
RHEL - 7.5 - 2.1.el7
OS Description:
Red Hat Virtualization Host 4.2.2 (el7.5)

Based on above result, z stream version can be shown on software info, changed this bug to verified.

Comment 37 errata-xmlrpc 2018-05-15 17:57:40 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://access.redhat.com/errata/RHSA-2018:1524

Comment 38 Franta Kust 2019-05-16 13:05:57 UTC
BZ<2>Jira Resync


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