Bug 714812

Summary: once a Resource is deleted via RHQ, if the underlying managed resource is later recreated and rediscovered by the Agent, it causes an invalid inventory report error in DiscoveryServerServiceImpl & prevents discovery of any new Resources from that Agent
Product: [Other] RHQ Project Reporter: Ian Springer <ian.springer>
Component: Core ServerAssignee: Lukas Krejci <lkrejci>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: high Docs Contact:
Priority: high    
Version: 4.2CC: bmachado, ccrouch, hrupp, lkrejci, mazz
Target Milestone: ---   
Target Release: JON 3.0.0, RHQ 4.3.0   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 678340, 729848, 745494    

Description Ian Springer 2011-06-20 20:59:05 UTC
To reproduce:

1) create a new child WAR resource (e.g. foo.war) via RHQ
2) delete foo.war via RHQ
3) re-create a foo.war child Resource via RHQ

Notice the create request succeeds, but foo.war is never discovered and added to inventory.

The Server log contains:

16:38:40,689 ERROR [DiscoveryServerServiceImpl] Received invalid inventory report from agent [Agent[id=0,name=jetengine,address=null,port=0,remote-endpoint=null,last-availability-report=null]]: Reported resource [Resource[id=10432, type=Web Application (WAR), key={default}foo.war, name=foo.war, parent=127.0.0.51:1099 default]] has an illegal inventory status of 'DELETED' - agents are not allowed to delete platforms from inventory.

The query [select * from RHQ_RESOURCE where name = 'foo.war'] returns:

id	resource_type_id	uuid	name	ancestry	resource_key	agent_id	inventory_status	connected	description	version	ctime	mtime	itime	res_configuration_id	plugin_configuration_id	modified_by	location	parent_resource_id	product_version_id
10432	10069	eaff0c16-de95-4a47-b7d5-571e7736678e	foo.war	10063_:_10004_:_127.0.0.51:1099 default_::_10008_:_10001_:_jetengine	{default}foo.war	10001	DELETED	f	a standalone web application (WAR)		20-Jun-2011 13:13:18	20-Jun-2011 13:26:02	20-Jun-2011 13:27:29	11533	12233	admin	null	10004	null

So the Resource is still in the Server's inventory but with the notorious DELETED inventory status.

Running the 'inventory' Agent prompt command shows:

      + Resource[id=10432, type=Web Application (WAR), key={default}foo.war, name=foo.war, parent=127.0.0.51:1099 default] (sync=NEW, state=STARTED, avail=UNKNOWN, sched=4/4)

This is pretty serious because the inventory report processing error on the Server prevents any other Resources from the same Agent from getting added to  Server inventory.

Deleting the Agent's data dir and restarting the Agent does *not* fix the issue. Most likely the only fix would be to manually delete the row with inv state DELETED from RHQ_RESOURCE.

Comment 1 Charles Crouch 2011-10-04 21:45:50 UTC
*** Bug 672943 has been marked as a duplicate of this bug. ***

Comment 2 Charles Crouch 2011-10-04 21:46:57 UTC
Note the unpleasant workaround from https://bugzilla.redhat.com/show_bug.cgi?id=672943, i.e. uninventory and reinventory the parent resource

Comment 3 Charles Crouch 2011-10-04 23:04:32 UTC
*** Bug 644409 has been marked as a duplicate of this bug. ***

Comment 4 Charles Crouch 2011-10-04 23:05:43 UTC
Note the nicer workaround from https://bugzilla.redhat.com/show_bug.cgi?id=644409:
"Running a full, manual, detailed discovery on the platform will fix the problem."
Also the potential patch attached to that issue

Comment 5 Lukas Krejci 2011-11-09 12:11:06 UTC
Could not reproduce. I tried a WAR and an EAR following the repro steps from this bug and from bug 672943 but could not reproduce this problem.

Pushing to ON_QA so that QA can have another stab at it as this is potentially a severe issue.

Comment 6 Mike Foley 2011-11-09 19:10:59 UTC
i tried the repro steps too and could not repro.

Comment 7 Mike Foley 2012-02-07 19:25:13 UTC
marking VERIFIED JON 3 bugs to CLOSED/CURRENTRELEASE

Comment 8 Mike Foley 2012-02-07 19:28:49 UTC
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE