Bug 1489567

Need to grab PRETTY_NAME from the host to present this info correctly.

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

(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

Marina, are you sure we used to report this?

Created attachment 1331227 [details]
RHEVH Version in UI - RHEV 3.6 (and any previous 3.x versions)

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.

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

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

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`

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.

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.

(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.

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?

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)

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?

(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).

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

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.

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

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

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/

Can the bug move to MODIFIED?

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.

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.

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

BZ<2>Jira Resync