Descriptionsefi litmanovich
2016-07-24 13:51:37 UTC
Created attachment 1183385[details]
ovirt-engine-setup-log
Description of problem:
Trying to upgrade a rhevm 3.6 to rhevm 4.0 fails in case there was a DC/Cluster with compatibility version 3.5. This seems to be the result of the following patch: https://gerrit.ovirt.org/55752 .
While this may be the wanted behaviour, I would argue that:
1. We need to have this constraint documented in some instruction of the upgrade flow between 3.6 to 4.0 (maybe there is one? I'd love to see it).
2. I would prefer that when doing engine-backup maybe some warning would be issued: "There is a cluster with compatibility version 3.5, please remove or upgrade the cluster in case this backup is intended from rhevm upgrade" or something of this sort.
Other choice is that maybe engine-setup will issue that warning and let user continue asking the user to upgrade or remove the cluster when setup is done. This I guess would be less preferable as it will put the responsibility on the user.
Version-Release number of selected component (if applicable):
ovirt-engine-setup-4.0.2-0.1.rc.el7ev.noarch
How reproducible:
always
Steps to Reproduce:
1. Have rhevm 3.6 engine with some dc and cluster set to comp version 3.5.
2. backup engine with:
engine-backup --mode=backup --file=engine_backup --log=backup.log
3. re provision the server and install rhel 7.2 with latest rhevm 4.0 repos.
4. install ovirt-engine/rhevm-setup.
5. restore engine with engine-backup --mode=restore --file=engine_backup --provision-db --log=restore.log --restore-permissions
6. engine-setup
Actual results:
[ ERROR ] Failed to execute stage 'Setup validation': Trying to upgrade from unsupported versions: 3.5
Expected results:
not sure, see options above.
Additional info:
W/A can be applied changing the compatibility_version value in DB from 3.5 to 3.6 on tables: vds_groups and stroage_pool.
(In reply to sefi litmanovich from comment #0)
> Additional info:
> W/A can be applied changing the compatibility_version value in DB from 3.5
> to 3.6 on tables: vds_groups and stroage_pool.
please do not do that. Do not even mention that:) as this is a sure way how to end up with unusable/corrupted setup eventually.
There is no actual workaround, all clusters and DCs just need to be updated to 3.6 before starting the upgrade. All we need to do is to make sure it's documented and one doesn't forget to do that by mistake