Bug 714812 - 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
once a Resource is deleted via RHQ, if the underlying managed resource is lat...
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Core Server (Show other bugs)
4.2
All All
high Severity high (vote)
: ---
: JON 3.0.0,RHQ 4.3.0
Assigned To: Lukas Krejci
Mike Foley
:
: 644409 672943 (view as bug list)
Depends On:
Blocks: jon3 rhq41 jon30-sprint8
  Show dependency treegraph
 
Reported: 2011-06-20 16:59 EDT by Ian Springer
Modified: 2013-08-05 20:39 EDT (History)
5 users (show)

See Also:
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:


Attachments (Terms of Use)

  None (edit)
Description Ian Springer 2011-06-20 16:59:05 EDT
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 17:45:50 EDT
*** Bug 672943 has been marked as a duplicate of this bug. ***
Comment 2 Charles Crouch 2011-10-04 17:46:57 EDT
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 19:04:32 EDT
*** Bug 644409 has been marked as a duplicate of this bug. ***
Comment 4 Charles Crouch 2011-10-04 19:05:43 EDT
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 07:11:06 EST
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 14:10:59 EST
i tried the repro steps too and could not repro.
Comment 7 Mike Foley 2012-02-07 14:25:13 EST
marking VERIFIED JON 3 bugs to CLOSED/CURRENTRELEASE
Comment 8 Mike Foley 2012-02-07 14:28:49 EST
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE

Note You need to log in before you can comment on or make changes to this bug.