Bug 1289508 - HostMaxSupportedClusterVersion shouldn't be read from vds.
HostMaxSupportedClusterVersion shouldn't be read from vds.
Status: CLOSED NOTABUG
Product: ovirt-engine
Classification: oVirt
Component: Frontend.Core (Show other bugs)
4.0.0
Unspecified Unspecified
unspecified Severity unspecified (vote)
: ---
: ---
Assigned To: Eli Mesika
Pavel Stehlik
infra
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-08 06:18 EST by Martin Mucha
Modified: 2016-02-10 14:44 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-23 07:44:26 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)

  None (edit)
Description Martin Mucha 2015-12-08 06:18:20 EST
Description of problem:
UI uses org.ovirt.engine.ui.uicommonweb.models.hosts.network.NetworkOperationFactory#getHostMaxSupportedClusterVersion() to figure out max supported cluster version. This version number is taken from host setting. However if such version does not exist (yet?) in org.ovirt.engine.core.compat.Version, vdc_option values will not be obtained from GetConfigurationValuesQuery and not stored in org.ovirt.engine.ui.uicommonweb.dataprovider.AsyncDataProvider#cachedConfigValuesPreConvert and UI code will fail on NPE.

Version-Release number of selected component (if applicable):


How reproducible:
100% if host and engine is out of sync with max supported version, otherwise 0%

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 1 Eli Mesika 2015-12-08 09:14:11 EST
This resulted from VDSM adding support for 4.0 and just after few hours the engine side patch that adds support for 4.0 merged 

Maybe we should always take the max version from the engine side since we always merge first the VDSM side supporting a new version and only then add the engine side support
Comment 2 Oved Ourfali 2015-12-15 05:01:09 EST
If the issue is only relevant in this use-case, then it isn't interesting.
Will it happen in other use-cases?
Comment 3 Martin Mucha 2015-12-15 05:38:44 EST
this can happens anywhere, where versions aren't in sync — I don't know if there can be (theoretically) customer running not just equal versions of engine/vdsm. If not, this can probably happen only during merging patches which sets vdsm/engine to higher versions.
Comment 4 Eli Mesika 2015-12-15 05:59:35 EST
(In reply to Oved Ourfali from comment #2)
> If the issue is only relevant in this use-case, then it isn't interesting.
> Will it happen in other use-cases?

AFAIK this can happen only in development when the VDSM patch supporting version x+1 is merged and the engine is still in version x
Comment 5 Oved Ourfali 2015-12-23 07:44:26 EST
(In reply to Eli Mesika from comment #4)
> (In reply to Oved Ourfali from comment #2)
> > If the issue is only relevant in this use-case, then it isn't interesting.
> > Will it happen in other use-cases?
> 
> AFAIK this can happen only in development when the VDSM patch supporting
> version x+1 is merged and the engine is still in version x

If that's the only case then I'm closing as NOTABUG.

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