This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 842767 - RHEVM reports "New RHEV-Hypervisor version available" falsely
RHEVM reports "New RHEV-Hypervisor version available" falsely
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal (Show other bugs)
3.0.5
Unspecified Unspecified
high Severity unspecified
: ---
: ---
Assigned To: Shahar Havivi
Tareq Alayan
infra
:
Depends On: 853092
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-24 10:40 EDT by paer.berge@gmail.com
Modified: 2016-02-10 14:06 EST (History)
13 users (show)

See Also:
Fixed In Version: si22
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-30 16:35:38 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description paer.berge@gmail.com 2012-07-24 10:40:59 EDT
Description of problem:
RHEV Manager says when host is selected:
"A new RHEV-Hypervisor version is available, an upgrade option will appear once the host is moved to maintenance mode."

Entering maintenance mode and selecting upgrade shows:
Current version: RHEV Hypervisor - 6.3 - 20120710.0.el6_3
RHEV-H ISO Name: rhevh-6.3-20120710.0.el6_3.iso

And running the upgrade will be "successful", but still report "A new RHEV-Hypervsior version is available" afterwards.

ISO version on the RHEV manager:
# ll /usr/share/rhev-hypervisor/
total 176132
-rw-r--r--. 1 root root 180355072 Jul 10 19:58 rhevh-6.3-20120710.0.el6_3.iso
lrwxrwxrwx. 1 root root        57 Jul 24 14:49 rhevh-latest-6.iso -> /usr/share/rhev-hypervisor/rhevh-6.3-20120710.0.el6_3.iso
lrwxrwxrwx. 1 root root        57 Jul 24 14:49 rhev-hypervisor6.iso -> /usr/share/rhev-hypervisor/rhevh-6.3-20120710.0.el6_3.iso
lrwxrwxrwx. 1 root root        57 Jul 24 14:49 rhev-hypervisor.iso -> /usr/share/rhev-hypervisor/rhevh-6.3-20120710.0.el6_3.iso
-rw-r--r--. 1 root root        21 Jul 10 20:04 version-6.3-20120710.0.el6_3.txt
lrwxrwxrwx. 1 root root        59 Jul 24 14:49 version.txt -> /usr/share/rhev-hypervisor/version-6.3-20120710.0.el6_3.txt


Version-Release number of selected component (if applicable):
RHEV-H
OS Version: RHEV Hypervisor - 6.3 - 20120710.0.el6_3
Kernel Version: 2.6.32 - 279.2.1.el6.x86_64
VDSM Version: 3.0.113.1

RHEV-M:
RHEV Manager for Servers and Desktops: 3.0.5_0001-5.el6_3


How reproducible:
Every time

Steps to Reproduce:
1. Select host in RHEV manager
2. Enter maintenance mode
3. Choose to Upgrade it
  
Actual results:
The hypervisor is successfully upgraded, but RHEV Manager still states "New RHEV-Hypervisor version is available"

Expected results:
No message saying "New version available" when already running latest version.

Additional info:
RHEV Manager is connected to a satellite and is updated with latest packages.
Comment 6 Itamar Heim 2012-08-15 10:01:54 EDT
*** Bug 839336 has been marked as a duplicate of this bug. ***
Comment 7 Andrew Cathrow 2012-08-15 18:50:57 EDT
When any applicable RHEV-H's are in the ISO directory then the "Upgrade or reinstall RHEV Hypervisor" link will appear

applicable RHEV-H's -> RHEV-H that's compatible with cluster, ie RHEL6.3 or higher for 3.1 and 6.2+ for 3.0
Comment 8 Einav Cohen 2012-08-16 11:13:50 EDT
Current logic compares the "major" part of the current version of the RHEV-H Host to the "major" part of the versions of the available RHEV-H ISOs.
If there is at least one available RHEV-H ISO with a match - we show the alert. Otherwise - we don't show the alert.

According to your last comment (comment #7): 
- We should take into consideration the level of the cluster to which the RHEV-H Host belongs:
   - in 3.0 cluster level: We should show alert only if there are available ISOs with version >= 6.2.
   - in 3.1 cluster level: We should show alert only if there are available ISOs with version >= 6.3.
- This means that we should *not* take into consideration the following when determining whether to show the alert or not:
   - 1. The current version of the RHEV-H Host.
   - 2. Available RHEV-H ISOs with version < 6.2.

Is that correct?
Comment 12 Einav Cohen 2012-08-20 03:28:48 EDT
I recommend:

- change the text according to Andrew's suggestion.

- In the backend GetoVirtISOs query (which accepts the host ID as a parameter): *In addition* to filtering according to major version, need to check compatibility version of the cluster to which the RHEV-H Host belongs, and return only ISOs versioned 6.2+ for cluster level 3.0 and ISOs versioned 6.3+ for cluster level 3.1.
Comment 13 Itamar Heim 2012-08-20 04:13:37 EDT
(In reply to comment #12)
> I recommend:
> 
> - change the text according to Andrew's suggestion.
> 
> - In the backend GetoVirtISOs query (which accepts the host ID as a
> parameter): *In addition* to filtering according to major version, need to
> check compatibility version of the cluster to which the RHEV-H Host belongs,
> and return only ISOs versioned 6.2+ for cluster level 3.0 and ISOs versioned
> 6.3+ for cluster level 3.1.

there are 6.3 iso's not providing 3.1 compatibility.
we don't have a way to correlate an iso with compatibility levels today, unless we ask to include these in the meta data of the iso (the .txt file, etc.)
Comment 14 Shahar Havivi 2012-08-23 07:31:47 EDT
posted at: http://gerrit.ovirt.org/#/c/7430/
Comment 15 Einav Cohen 2012-08-26 07:25:53 EDT
(In reply to comment #13)
> (In reply to comment #12)
> > I recommend:
> > 
> > - change the text according to Andrew's suggestion.
> > 
> > - In the backend GetoVirtISOs query (which accepts the host ID as a
> > parameter): *In addition* to filtering according to major version, need to
> > check compatibility version of the cluster to which the RHEV-H Host belongs,
> > and return only ISOs versioned 6.2+ for cluster level 3.0 and ISOs versioned
> > 6.3+ for cluster level 3.1.
> 
> there are 6.3 iso's not providing 3.1 compatibility.

I simply detailed requirements mentioned in comment #7...

> we don't have a way to correlate an iso with compatibility levels today,
> unless we ask to include these in the meta data of the iso (the .txt file,
> etc.)

- Then a blocking BZ on RHEV-H should be opened to supply these?

- Should the compat-levels of the ISOs be compared to the compat-levels reported by vdsm on the RHEV-H Host, or to the compat-level of the cluster to which the RHEV-H Host belongs? (the latter, I assume)

- The ISO compat-levels (once provided) are the only thing that should be taken into consideration? 
E.g., if I have a RHEV-H 6.3 Host which belongs to cluster 3.1, and I have an available RHEV-H 7 ISO that reports 3.1 as a supported cluster-level, should we display it as an optional upgrade ISO for the RHEV-H 6.3 Host? Or should we still use the "major version" comparison on top of everything?
Comment 16 Itamar Heim 2012-08-30 06:42:21 EDT
einav - good question. since there is no upgrade between major versions, probably a combination of both.

mike - like the txt file we have with the version, we want to have the vdsm compatibility versions as well (same file, another one).
since it changes every 6 or 12 months, i think just having this file hard coded and updating manually would be best.

thoughts?
Comment 17 Mike Burns 2012-08-30 09:12:58 EDT
(In reply to comment #16)
> einav - good question. since there is no upgrade between major versions,
> probably a combination of both.
> 
> mike - like the txt file we have with the version, we want to have the vdsm
> compatibility versions as well (same file, another one).
> since it changes every 6 or 12 months, i think just having this file hard
> coded and updating manually would be best.

It's certainly possible to do that.  I don't particularly like having it hard-coded, but i'm not sure there is a way to do it programatically in the current build process.  

Please file a separate bz against rhev-h with the expected format and I'll look at what we can do.


> 
> thoughts?
Comment 18 Einav Cohen 2012-08-30 09:42:41 EDT
(In reply to comment #17)
>
> ...
> 
> Please file a separate bz against rhev-h with the expected format and I'll
> look at what we can do.
> 

Bug 842767
No exact format is supplied there yet; Shahar / someone from rhev-m infra team should work on that and supply the exact format.
Comment 19 Einav Cohen 2012-08-30 09:43:31 EDT
(In reply to comment #18)
> (In reply to comment #17)
> >
> > ...
> > 
> > Please file a separate bz against rhev-h with the expected format and I'll
> > look at what we can do.
> > 
> 
> Bug 842767

correction: Bug 853092

> No exact format is supplied there yet; Shahar / someone from rhev-m infra
> team should work on that and supply the exact format.
Comment 20 Barak 2012-08-30 11:57:33 EDT
Currently the above BZ (Bug 853092)  is flagged for rhel-6.4.0,
So what are our plans for 6.3 ?
Do we just change the comment or do we try to push the above BZ to rhel-6.3.z ?
Comment 24 Andrew Cathrow 2012-10-18 14:28:15 EDT
Can we commit this without the 6.3.z backport for the RHEV-H metadata file?
Comment 25 Mike Burns 2012-10-18 14:32:43 EDT
(In reply to comment #24)
> Can we commit this without the 6.3.z backport for the RHEV-H metadata file?

the vdsm-compatibility.txt file?  It exists on 6.3.z already...
Comment 26 Shahar Havivi 2012-10-18 14:48:49 EDT
(In reply to comment #24)
> Can we commit this without the 6.3.z backport for the RHEV-H metadata file?

Yes,
the vdsm-cmpatibility.xxx.txt file is unnecessary - we have tests that check it with and without this file
Comment 27 Itamar Heim 2012-10-18 14:49:56 EDT
but we don't require it, and we may have older iso's without it as well. we should be able to handle them.

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