Bug 842767
| Summary: | RHEVM reports "New RHEV-Hypervisor version available" falsely | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | paer.berge <paer.berge> |
| Component: | ovirt-engine-webadmin-portal | Assignee: | Shahar Havivi <shavivi> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Tareq Alayan <talayan> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | high | ||
| Version: | 3.0.5 | CC: | acathrow, bazulay, dyasny, ecohen, iheim, lpeer, mburns, oramraz, pstehlik, Rhev-m-bugs, sgrinber, ykaul, yzaslavs |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | infra | ||
| Fixed In Version: | si22 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-01-30 21:35:38 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Infra | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 853092 | ||
| Bug Blocks: | |||
|
Description
paer.berge@gmail.com
2012-07-24 14:40:59 UTC
*** 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 ? 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. |