+++ This bug is a downstream clone. The original bug is: +++ +++ bug 1636469 +++ ====================================================================== Description of problem: When removing a RHV-H or RHEL-H Host from the UI, the remove dialog shows a note at the bottom recommending to undeploy HostedEngine on host before removing it while the setup was never used as HostedEngine environment. Version-Release number of selected component (if applicable): rhevm-4.1.8.2-0.1.el7 ovirt-hosted-engine-ha-2.2.14-1.el7ev vdsm-4.20.32-1.el7ev How reproducible: 100% Steps to Reproduce: 1. In a standard environment (no SHE), place a RHV-H host into maintenance and click the remove button. This is for a 4.1 environment, the host has to be RHV-H, in 4.2 it doesn't matter which type of host this is. Actual results: A note at the bottom of the Remove dialog would appear with: "The hosts marked with * still have hosted engine deployed on them. Hosted engine should be undeployed before they are removed." This could confuse users Expected results: Identify if the host really has HostedEngine deployed and report accordingly Additional info: Issue was identified in code in: https://github.com/oVirt/ovirt-hosted-engine-ha/blob/master/ovirt_hosted_engine_ha/env/config.py#L189-L196 This behavior will always be true in 4.2 for any type of Host (ovirt-node or RHEL) since we now require hosted-engine packages to be installed in RHEL, ovirt-node comes preinstalled with hosted-engine packages Host can still be removed without issues. (Originally by Javier Coscia)
In RHV 4.2, any registered RHV-H or RHEL-H will be set in the DB with 'hosted_engine_configured' = 't' This is because the RHVH image already has the ovirt-hosted-engine-setup and ovirt-hosted-engine-ha packages pre-installed VDSM will report "hostedEngineDeployed": true, by getCapabilities and the DB will be updated with 'hosted_engine_configured' = 't', later, when you try to remove the host you will get an * next to the host name and at the bottom a note saying: "The hosts marked with * still have hosted engine deployed on them. Hosted engine should be undeployed before they are removed." Although you can still remove the host without any issues, the message could confuse users. We should not rely only if the package is installed or not, and check something else like the real presence of the hosted-engine.conf file. This was the intention as per https://bugzilla.redhat.com/show_bug.cgi?id=1392957 and https://gerrit.ovirt.org/#/c/67721 & https://gerrit.ovirt.org/#/c/67706 I believe this was introduced by https://bugzilla.redhat.com/show_bug.cgi?id=1543988 & https://gerrit.ovirt.org/#/c/87536/ ~~~ [root@rhvh41 ~]# vdsm-client Host getCapabilities "version_name": "Snow Man", "lastClientIface": "lo", "cpuCores": "2", "hostedEngineDeployed": true, <<<<<<<<<<<<<<<<<<<<< "guestOverhead": "65", "additionalFeatures": [ "libgfapi_supported" ], ~~~ On a RHEL-H, if you remove ovirt-hosted-engine-setup & ovirt-hosted-engine-ha and rebooted the host, after that, the getCapabilities reports false for hostedEngineDeployed and the 'hosted_engine_configured' field in 'vds_dynamic' table changes to 'f', place the host into maintenance and click remove, there's no message saying you need to undeployed before remove. In RHV 4.2 we started to install ovirt-hosted-engine-setup & ovirt-hosted-engine-ha packages in RHEL-H hosts too, so the result will be the same on any type of host added into RHV 4.2. (Originally by Javier Coscia)
Verified on: ovirt-engine-4.2.8.2-0.0.master.20181214143021.gite3e4917.el7.noarch vdsm-4.20.45-6.git647ac46.el7.x86_64 ovirt-hosted-engine-setup-2.2.33-0.0.master.20181105145335.git470d6c6.el7.noarch ovirt-hosted-engine-ha-2.2.19-1.el7.noarch Pre-required: RHV environment without SHE. 1. Check host flag: # vdsm-client Host getCapabilities | grep hostedEngineDeployed 2. Move host to maintenance. 3. Remove Host. Results: "hostedEngineDeployed": false Removing the host didn't show a note recommending to undeploy HostedEngine on host before removing it.
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/RHBA-2019:0118