Bug 1636469
| Summary: | Removing a non-HE Host recommends user to undeploy HostedEngine on it first | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Javier Coscia <jcoscia> | |
| Component: | ovirt-hosted-engine-ha | Assignee: | Simone Tiraboschi <stirabos> | |
| Status: | CLOSED ERRATA | QA Contact: | Liran Rotenberg <lrotenbe> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | high | |||
| Version: | 4.2.6 | CC: | lsurette, mavital, stirabos | |
| Target Milestone: | ovirt-4.3.0 | Keywords: | ZStream | |
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | v2.3.0 | Doc Type: | Bug Fix | |
| Doc Text: |
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.
Fixing it correctly detecting HE deploy status.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1658054 (view as bug list) | Environment: | ||
| Last Closed: | 2019-05-08 12:31:57 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | Integration | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1658054 | |||
|
Description
Javier Coscia
2018-10-05 13:27:00 UTC
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. Verified on: ovirt-engine-4.3.0-0.4.master.20181207184726.git7928cae.el7.noarch vdsm-4.30.4-36.git6698e62.el7.x86_64 ovirt-hosted-engine-ha-2.3.0-0.2.master.20181212075523.gitde89e03.el7.noarch ovirt-hosted-engine-setup-2.3.0-0.2.master.20181211213852.git82b1918.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/RHEA-2019:1049 |