Only Versions 3.6 and 4.0 are to be deprecated. The documentation should be updated accordingly.

Note: the deprecation is UX only. The backing code paths in VDSM/engine will not be removed (nacked), so we're pretty much just hiding vdc_options, which users can still set from engine-config if they need them.

Verified on 4.3.0-0.8.rc2.el7.
The following test scenarios were tested:
1. In engine creating data centers and clusters with versions 3.6 or 4.0 (both UI and RESTAPI) failed with error selected compatibility version is not supported as it should.
2. Upgrading engine from 4.2 to 4.3
    a. When 4.2 setup contains at least 1 data center or cluster with version 3.6 or 4.0, then upgrade to 4.3 failed as it should
    b. When 4.2 setup contains only data centers or clusters with version 4.1 and higher then the upgrade continue as it should

Hi, what is the expected behaviour in case of VMs with pending changes originated by a previous cluster compatibility change?

scenario:

a) a VM was created on cluster at compatibility level 4.0 
b) cluster compatibility has been increased to level 4.1 or maybe even to 4.2
c) VM for business reasons has not yet being stopped to apply the pending changes, so technically they are still in 4.0 mode

Will RHV be able to correctly handle those?
Will the update be denied to environments with VM with pending changes or should be the CU to ensure that no VM has pending changes before upgrading?


thanks

(In reply to Andrea Perotti from comment #17)
> Hi, what is the expected behaviour in case of VMs with pending changes
> originated by a previous cluster compatibility change?
> 
> scenario:
> 
> a) a VM was created on cluster at compatibility level 4.0 
> b) cluster compatibility has been increased to level 4.1 or maybe even to 4.2
> c) VM for business reasons has not yet being stopped to apply the pending
> changes, so technically they are still in 4.0 mode
> 
> Will RHV be able to correctly handle those?

At the moment we are just blocking upgrade to 4.3 if there is existing data center or cluster with 3.6/4.0 compatibility level, but we don't check VM level

> Will the update be denied to environments with VM with pending changes or
> should be the CU to ensure that no VM has pending changes before upgrading?

Ryan, this is out of my knowledge, could you please aswer above?

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2019:1085

*** Bug 1455525 has been marked as a duplicate of this bug. ***