Bug 1324447 - Report "pretty name" as a part of host OS data to distinguish between EL7 and NGN hosts
Summary: Report "pretty name" as a part of host OS data to distinguish between EL7 and...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: vdsm
Classification: oVirt
Component: Core
Version: 4.18.0
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ovirt-4.0.2
: ---
Assignee: Eli Mesika
QA Contact: Lucie Leistnerova
URL:
Whiteboard: infra
: 1332466 (view as bug list)
Depends On:
Blocks: 1346782
TreeView+ depends on / blocked
 
Reported: 2016-04-06 10:54 UTC by Tareq Alayan
Modified: 2016-08-29 11:29 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-08-22 12:31:25 UTC
oVirt Team: Infra
Embargoed:
rule-engine: ovirt-4.0.z+
rule-engine: planning_ack+
mperina: devel_ack+
lsvaty: testing_ack+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 57620 0 None ABANDONED vdsm: adding handling for NGN in osinfo.py 2020-08-25 15:53:16 UTC
oVirt gerrit 59463 0 master ABANDONED add pretty name to OS version 2020-08-25 15:53:16 UTC
oVirt gerrit 60433 0 ovirt-4.0 MERGED vdsm: adding handling for NGN in osinfo.py 2020-08-25 15:53:17 UTC

Description Tareq Alayan 2016-04-06 10:54:54 UTC
Description of problem:
A rhevh-h-next node have <type>rhel</type> in the rest api response

Version-Release number of selected component (if applicable):
rhevm-3.6.5.1-0.1.el6.noarch

How reproducible:
always

Steps to Reproduce:
via rest api client
https://{engine-url}/api/hosts/{host-uuid}

Actual results:
<type>rhel</type>

expected results:
<type>ovirt-node-next v111 on centos v7.7</type>


via UI 
mark the host and click on the software tab you will see something like 

Actual results:
OS Version: RHEL - 7 - 2.1511.el7.centos.2.10

Expected results:
ovirt-node-next v111 on centos v7.7

Comment 1 Sandro Bonazzola 2016-05-02 09:53:13 UTC
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.

Comment 2 Eli Mesika 2016-05-16 10:39:34 UTC
Looking in the XMLRPC struct returned to the engine I see that we look for a "operatingSystem" field in that structure 
While debugging the code I go the following values for "operatingSystem":

release" -> "2.1511.el7.centos.2.10
version" -> "7
name" -> "RHEL

On he other hand , looking in the os_release file on the node I see the following :

NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
VARIANT="oVirt Node 4.0.0_master"
VARIANT_ID="ovirt-node"
PRETTY_NAME="oVirt Node 4.0.0_master"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.ovirt.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"

So, it seems that the problem origin is in VDSM

Comment 3 Yaniv Lavi 2016-05-23 13:15:59 UTC
oVirt 4.0 beta has been released, moving to RC milestone.

Comment 4 Yaniv Lavi 2016-05-23 13:21:24 UTC
oVirt 4.0 beta has been released, moving to RC milestone.

Comment 5 Fabian Deutsch 2016-06-09 11:03:59 UTC
The propper - and upstream aligned - handling is probably to include the id and variant_id fields of the os-release file.

This tuple should allow to identify hosts reliably.

Comment 6 Fabian Deutsch 2016-06-09 11:04:15 UTC
*** Bug 1332466 has been marked as a duplicate of this bug. ***

Comment 7 Martin Perina 2016-06-15 10:55:20 UTC
We decided to add pretty-name to current host OS identification (name, version, release) reported by VDSM ti distinguish between EL7 and NGN based on EL7.

Comment 8 Martin Perina 2016-07-07 14:33:28 UTC
Moving back to POST as backport to ovirt-engine-4.0 branch is needed

Comment 9 Martin Perina 2016-07-12 15:01:44 UTC
All patches are merged and there should be no risk around stability in those patches, so moving to 4.0.2

Comment 10 Martin Perina 2016-07-21 09:45:45 UTC
Setting target release to 4.18.8 as it's contained in latest VDSM build for ovirt-4.0.2-RC1

Comment 11 Lucie Leistnerova 2016-08-18 07:39:02 UTC
vdsm returns pretty name

	operatingSystem = {'name': 'RHEL',
	                   'pretty_name': 'Red Hat Virtualization Host 4.0 (el7.2)',
	                   'release': '1.el7',
	                   'version': '4.0'}


verified in vdsm-4.18.11-1.el7ev.x86_64

Comment 12 Fabian Deutsch 2016-08-18 08:00:05 UTC
this is actually wrong, it should be release=$RHEL_RELEASE, version=$RHEL_VERSION

Can you paste /etc/os-release, /etc/system-release, /etc/system-release-cpe and /etc/redhat-release  of the host?

Only pretty name should contain the RHV version/release

Comment 13 Red Hat Bugzilla Rules Engine 2016-08-18 08:00:11 UTC
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

Comment 14 Lucie Leistnerova 2016-08-18 08:09:19 UTC
# cat /etc/os-release
NAME="Red Hat Enterprise Linux"
VERSION="7.2"
VERSION_ID="7.2"
ID="rhel"
ID_LIKE="fedora"
VARIANT="Red Hat Virtualization Host"
VARIANT_ID="ovirt-node"
PRETTY_NAME="Red Hat Virtualization Host 4.0 (el7.2)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:7.2:GA:hypervisor"
HOME_URL="https://www.redhat.com/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"

# FIXME
REDHAT_BUGZILLA_PRODUCT="Red Hat Virtualization"
REDHAT_BUGZILLA_PRODUCT_VERSION=7.2
REDHAT_SUPPORT_PRODUCT="Red Hat Virtualization"
REDHAT_SUPPORT_PRODUCT_VERSION=7.2

# cat /etc/system-release
Red Hat Enterprise Linux release 7.2

# cat /etc/system-release-cpe
cpe:/o:redhat:enterprise_linux:7.2:ga:hypervisor

# cat /etc/redhat-release
Red Hat Enterprise Linux release 7.2


GUI: Hosts - General - Software

OS Version:
RHEL - 4.0 - 1.el7
OS Description:
Red Hat Virtualization Host 4.0 (el7.2)

Comment 15 Fabian Deutsch 2016-08-18 08:18:16 UTC
Ok, it's wrong  in the UI, but coirrect in the files.
vdsm must be pulling it from the incorrect source.

Eli, can you clarify where vdsm is pulling the version from? I currently can't see swhere it is getting the "4.0" version from.

Comment 16 Martin Perina 2016-08-18 09:02:18 UTC
(In reply to Fabian Deutsch from comment #15)
> Ok, it's wrong  in the UI, but coirrect in the files.
> vdsm must be pulling it from the incorrect source.
> 
> Eli, can you clarify where vdsm is pulling the version from? I currently
> can't see swhere it is getting the "4.0" version from.

Fabian, VDSM uses the same code as for RHEL, so we are getting version and release from querying basename package.

Comment 17 Fabian Deutsch 2016-08-18 09:37:45 UTC
How do you identify the basename package?

The assumption was that one of /etc/os-release, /etc/system-release, /etc/system-release-cpe and /etc/redhat-release was directly or indirectly used.

Comment 19 Fabian Deutsch 2016-08-18 12:10:22 UTC
Okay, this explains it.

So not the contents of this file is used, but rather the version/release of the owner of that file.

Which is a different release file on Node.

In the UI it is not to much of an issue.
But I suppose tha this version/released is used for some decision, i.e. allowed update?

Comment 20 Fabian Deutsch 2016-08-19 08:03:43 UTC
I've opened bug 1368364 to track the incorrect reporting.

Ths bug is actually verified, because pretty name is reported correctly.

Comment 21 Martin Perina 2016-08-29 11:29:30 UTC
Discussed over BJ, clearing needinfo


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