Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1146183

Summary:	Possible problem with plugin dependency graph or plugin update order with runs-inside
Product:	[JBoss] JBoss Operations Network	Reporter:	Jay Shaughnessy <jshaughn>
Component:	Core Server	Assignee:	RHQ Project Maintainer <rhq-maint>
Status:	CLOSED NOTABUG	QA Contact:	Mike Foley <mfoley>
Severity:	high	Docs Contact:
Priority:	high
Version:	JON 3.3.0	CC:	loleary, myarboro
Target Milestone:	---
Target Release:	JON 3.3.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-12-18 00:15:32 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jay Shaughnessy 2014-09-24 17:26:37 UTC

Creating a new bug for something reported in Bug 1144998:

On upgrade to JON 3.3.0 ER03 see in server log on startup:

07:10:42,526 WARN  [org.rhq.core.clientapi.agent.metadata.PluginMetadataParser] (pool-6-thread-1) There is no resource type named [Servicemix3 Server] from a plugin named [Servicemix3]. This is probably because that plugin is missing. Resource Type [{ActiveMQ}Broker] will not have that missing type as a possible parent.


Looking at the Fuse plugin pack, which has the relevant plugins, the activeMq plugin declares:

    <runs-inside>
      <parent-resource-type name="ActiveMQ Server" plugin="ActiveMQ"/>
      <parent-resource-type name="JMX Server" plugin="JMX"/>
      <parent-resource-type name="Servicemix3 Server" plugin="Servicemix3"/>
      <parent-resource-type name="Servicemix4 Server" plugin="Servicemix4"/>
      <parent-resource-type name="Fabric Container" plugin="Fabric"/>
      <parent-resource-type name="JBoss Fuse Container" plugin="JBossFuse"/>
      <parent-resource-type name="JBossAS Server" plugin="JBossAS"/>
    </runs-inside>


And the "Servicemix3 Server" type does seem to exist in the Servicemix3 plugin descriptor.  But the ActiveMQ plugin is updating its types before the Servicemix3 plugin is processed.

See the servr log attached to Bug 1144998 (https://bugzilla.redhat.com/attachment.cgi?id=939910).


Expected results:
valid plugins should load.

Comment 1 John Mazzitelli 2014-09-24 18:03:22 UTC

Was the Servermix3 plugin actually deployed? The runs-inside are considered optional - you'll get that warning message if the plugin referred to in the plugin attribute of <parent-resource-type> doesn't exist/wasn't deployed.

Comment 2 Jay Shaughnessy 2014-09-24 18:18:57 UTC

If you look at the attached log for Bug 1144998 you can see that the types for Servermix3 were process after the ActiveMQ types.  That seems like it may be a problem.

Comment 3 John Mazzitelli 2014-09-25 21:48:30 UTC

Of course, I can't replicate. I took a master build and before rhqctl install, I put the 3.2.0 fuse plugin pack in /plugins. Installed, started, deployed fine.

Then shutdown the server, copied the 3.3 fuse plugin pack to /plugins, restarted server, and watched the new updated plugins deployed fine and in the correct order.

Will need to figure out what the difference is in my steps and the steps taken to see the bug.

Comment 4 John Mazzitelli 2014-09-26 19:10:00 UTC

It looks like it was able to eventually deploy the metadata propertly From the server logs I see this:

07:10:42,526 WARN  [org.rhq.core.clientapi.agent.metadata.PluginMetadataParser] (pool-6-thread-1) There is no resource type named [Servicemix3 Server] from a plugin named [Servicemix3]. This is probably because that plugin is missing. Resource Type [{ActiveMQ}Broker] will not have that missing type as a possible parent.

...

07:18:39,484 INFO  [org.rhq.enterprise.server.resource.metadata.ResourceMetadataManagerBean] (http-/0.0.0.0:7080-11) Adding ResourceType [ActiveMQ:Broker(id=10177)] as child of ResourceType [Servicemix3:Servicemix3 Server(id=10192)]...

So it eventually got it right.

Not sure if there is anything to do here.

Comment 5 Jay Shaughnessy 2014-09-26 20:03:53 UTC

This can probably be closed as not-a-bug.  I'll set it to post-ga just in case PM wants this logging moved to debug level, but then it could mask an actual plugin deployment issue.  I suppose it could be INFO level or perhaps have additional text saying the issue may get resolved later in type processing.

Comment 6 Larry O'Leary 2014-12-18 00:15:32 UTC

As per comment 5, closing as NOTABUG. If any additional work is needed here, it can probably be captured upstream. From the looks of it, the behavior was a bit confusing but expected.