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.
*** Bug 839336 has been marked as a duplicate of this bug. ***
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
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?
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.
(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.)
posted at: http://gerrit.ovirt.org/#/c/7430/
(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?
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?
(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?
(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.
(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.
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 ?
merged at: http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=30aaeea44f13e176a53286fc44985287e18bfaaa
Can we commit this without the 6.3.z backport for the RHEV-H metadata file?
(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...
(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
but we don't require it, and we may have older iso's without it as well. we should be able to handle them.