Bug 1535268

Summary:	HE Undeploy leaves host metadata on shared storage.
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Germano Veit Michel <gveitmic>
Component:	ovirt-engine	Assignee:	Nobody <nobody>
Status:	CLOSED WONTFIX	QA Contact:	Polina <pagranat>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.1.8	CC:	akrejcir, gveitmic, lsurette, mkalinin, rbalakri, Rhev-m-bugs, srevivo, ykaul, ylavi
Target Milestone:	---	Flags:	lsvaty: testing_plan_complete-
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-06-13 12:34:00 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	SLA	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Germano Veit Michel 2018-01-17 00:58:44 UTC

Description of problem:

Undeploy works fine, the configuration is removed and the agent is stopped. However, the metadata for the host on shared storage is left behind. 

This does not cause any problems, but it leaves pollution on the output of hosted-engine --vm-status and may confuse the administrator if the host was really removed or something went wrong. It shows as a stale host, not stopped, not in local maintenance. Just left there, as if the host died. 

Perhaps it would be more user friendly if this was cleaned up during Undeploy.

--== Host 3 status ==--

conf_on_shared_storage             : True
Status up-to-date                  : False
Hostname                           : 10.64.24.171
Host ID                            : 3
Engine status                      : unknown stale-data
Score                              : 2601
stopped                            : False
Local maintenance                  : False
crc32                              : 7b82abf2
local_conf_timestamp               : 1158
Host timestamp                     : 1157
Extra metadata (valid at timestamp):
	metadata_parse_version=1
	metadata_feature_version=1
	timestamp=1157 (Wed Jan 17 10:20:55 2018)
	host-id=3
	score=2601
	vm_conf_refresh_time=1158 (Wed Jan 17 10:20:56 2018)
	conf_on_shared_storage=True
	maintenance=False
	state=GlobalMaintenance
	stopped=False



Version-Release number of selected component (if applicable):
rhevm-4.1.8.2-0.1.el7.noarch

How reproducible:
100%

Steps to Reproduce:
1. Undeploy host

Actual results:
Host metadata on SD left behind.

Expected results:
Host metadata cleaned up

Comment 4 Martin Sivák 2018-06-04 16:24:33 UTC

Hi Germano, the undeploy should leave the host there, that is intentional. But, a properly stopped agent should be reported as stopped=True in the report. Maybe we could check and fix that part.

Comment 5 Andrej Krejcir 2018-06-07 11:18:37 UTC

Is the 'hosted-engine --vm-status' output, written in the bug description, for the undeployed host? If it is, there is 'stopped=False' and we should fix it.

Comment 6 Germano Veit Michel 2018-06-07 22:44:55 UTC

Andrej and Martin,

I remembered I split the 'False' problem from this bug. The part of the agent dying ungracefully and leaving it like that is here, I believe.

https://bugzilla.redhat.com/show_bug.cgi?id=1535796

Please correct me if I'm wrong.

And if the metadata is supposed to stay on the shared storage then we can close this bug.

Comment 7 Martin Sivák 2018-06-13 12:34:00 UTC

Closing per Germano's comment. We should address the stopped=False that is tracked by different bug.

Comment 8 Franta Kust 2019-05-16 13:08:26 UTC

BZ<2>Jira Resync