Description of problem: after discussion about https://bugzilla.redhat.com/show_bug.cgi?id=1444450 here is RFE to make db update scripts correct the value of vds_type for NGN which were added in 3.6 engine (ie. 3.6 version host-deploy didn't know about NGN and thus put wrong vds_type into the DB). This issue is possible to solve in 4.0 engine with 'Reinstall' but in 4.1 engine 'Reinstall' of 3.6 ngn - _just_ to correct vds_type - fails as 3.6 ngn doesn't have collectd. In our opinion if db update scripts would correct it transparently users would not need to do 'Reinstall' in 4.0 and in 4.1 as well, and in 4.1 this would not make 3.6 ngn fail. engine=# select vds_name,pretty_name,rpm_version,vds_type from vds; vds_name | pretty_name | rpm_version | vds_type ----------------+-----------------------------------------+----------------------+---------- dell-r210ii-13 | Red Hat Virtualization Host 3.6 (el7.3) | vdsm-4.17.39-1.el7ev | 0 (1 row) Version-Release number of selected component (if applicable): 100% How reproducible: 100% Steps to Reproduce: 1. add 3.6 ngn into 3.6 engine 2. update engine to 4.0 3. see if vds_type is still incorrect or 2b. update to 4.1 3b. see if vds_type is still incorrect (if not caught by 4.0 update) Actual results: - in 4.0 user needs to do manual workaround to correct vds_type value inserted wrongly by uninformed of NGN host-deploy - in 4.1 user doing above workaround finishes with install failed host :/ Expected results: vds_type is correct after update and no manual workaround needed Additional info:
Thus plz consider at least for both 4.0 and 4.1.
(In reply to Jiri Belka from comment #0) > Description of problem: > > after discussion about https://bugzilla.redhat.com/show_bug.cgi?id=1444450 > here is RFE to make db update scripts correct the value of vds_type for NGN > which were added in 3.6 engine (ie. 3.6 version host-deploy didn't know > about NGN and thus put wrong vds_type into the DB). This issue is possible > to solve in 4.0 engine with 'Reinstall' but in 4.1 engine 'Reinstall' of 3.6 > ngn - _just_ to correct vds_type - fails as 3.6 ngn doesn't have collectd. > > In our opinion if db update scripts would correct it transparently users > would not need to do 'Reinstall' in 4.0 and in 4.1 as well, and in 4.1 this > would not make 3.6 ngn fail. > > engine=# select vds_name,pretty_name,rpm_version,vds_type from vds; > vds_name | pretty_name | rpm_version > | vds_type > ----------------+-----------------------------------------+------------------ > ----+---------- > dell-r210ii-13 | Red Hat Virtualization Host 3.6 (el7.3) | > vdsm-4.17.39-1.el7ev | 0 > (1 row) > Problems: 1. Reporting of pretty_name is a 4.0 feature, so in order to fill this value you need to finish upgrade to 4.0, start the engine and finish at least one execution of host monitoring 2. DB upgrade scripts are executed as a part of upgrade, so they are already applied before 4.0 engine starts up and fill in pretty_name value Possible solutions: A. 4.1 db upgrade script - Add upgrade script to fix host type into 4.1 only - Let customer upgrade to 4.0, start engine and finish monitoring execution - Continue upgrade to 4.1 (after upgrade to 4.1 all hosts should have correct type, but customers not will to upgrade to 4.1 you would still need to perform reinstall) B. Connect to the hosts during engine-setup - add a plugin to 4.0 engine-setup which will try to connect to all hosts using SSH, get /etc/os-release and update host type in db accordingly - not reliable as all host may not be reachable We have already discussed a bunch of other ideas within infra team a none of the solutions were 100% reliable, the only reliable way is to perform Reinstall after upgrade to 4.x B. Connect to the hosts during engine-setup
In my opinion, option B is more complex than backporting pretty_name to 3.6.z, and should be avoided. Option A is simple, safe, incomplete - but would help those users who have "stopped by" in 4.0 before upgrade to 4.1. Host reinstallation for a complete cluster is a lengthy process that any customer would appreciate to avoid.
(In reply to Dan Kenigsberg from comment #3) > In my opinion, option B is more complex than backporting pretty_name to > 3.6.z, and should be avoided. > > Option A is simple, safe, incomplete - but would help those users who have > "stopped by" in 4.0 before upgrade to 4.1. Host reinstallation for a > complete cluster is a lengthy process that any customer would appreciate to > avoid. Right, if we backport pretty name into 3.6.z on both sides (BZ1346782 for engine and BZ1324447 for VDSM), then we could create 4.0.z db upgrade script which would fix host type during the upgrade. This would the issue for customers upgrading from latest 3.6.11 to 4.0.z (assuming we will backport pretty name to 3.6.11). And it will also help those customers who already upgraded to 4.0, because they already have pretty name field populated.
Moving bug to Eli per his request. He believes that it should be an easy fix.
Update engine 3.6 -> 4.0 -> 4.1 was successful, vds_type for NGN was set to 1, host are running and check for hosts upgrade is ok. verified in ovirt-engine-4.1.3.1-0.1.el7.noarch