Bug 691476 - Grouping fails due to Resource Key is too unique for the same resource across compatible parents
Summary: Grouping fails due to Resource Key is too unique for the same resource across...
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: Resource Grouping (Show other bugs)
(Show other bugs)
Version: 4.0.0
Hardware: All All
high
medium vote
Target Milestone: ---
: ---
Assignee: Charles Crouch
QA Contact: Mike Foley
URL:
Whiteboard:
Keywords:
: 601194 (view as bug list)
Depends On:
Blocks: jon3 jon3-sprint1 715334
TreeView+ depends on / blocked
 
Reported: 2011-03-28 16:28 UTC by Larry O'Leary
Modified: 2018-11-14 13:42 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-03 16:59:27 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Screenshot_admin-console.war (79.41 KB, image/png)
2011-05-26 09:07 UTC, Sunil Kondkar
no flags Details
Screenshot_run.sh (89.77 KB, image/png)
2011-05-26 09:08 UTC, Sunil Kondkar
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Legacy) 55095 None None None Never
Red Hat Bugzilla 601194 None None None Never

Description Larry O'Leary 2011-03-28 16:28:21 UTC
When viewing compatible groups of resources and their children, the same resource will be displayed multiple times in the group view. 

For example, if you have a two node EAP 5 cluster:

   JBOSS_HOME=/opt/jboss/eap/jboss-eap-5.1/jbossas
   NODE1_CONF=Node1
   NODE2_CONF=Node2

The result is that the resource key for an EAR deployed to the cluster becomes too unique for the grouping to see that the resource is the same.

   etat.ear (Node1) Resource Key: vfsfile:/opt/jboss/eap/jboss-eap-5.1/jboss-as/server/Node1/deploy/etat.ear/
   etat.ear (Node2) Resource Key: vfsfile:/opt/jboss/eap/jboss-eap-5.1/jboss-as/server/Node2/deploy/etat.ear/


This issue can be seen by simply importing two JBoss EAP 5 instances into inventory which use two different configuration directories, adding them to a compatible group, and then looking at the admin-console.war application in the group view.

Comment 1 John Mazzitelli 2011-04-01 15:30:11 UTC
this is an issue with the jboss-5 plugin. its creating unique resource keys across all resources, not just across peer resources

Comment 2 Charles Crouch 2011-04-08 20:40:12 UTC
I bet this is a problem for lots of other resources types too. We will need to check those and assess the impact of fixing those other occurrences.

Comment 3 Rafael Soares (Tuelho) 2011-04-27 22:48:21 UTC
Would be interesting consider the scenario shown in this topic: http://community.jboss.org/message/602370

Comment 4 Ian Springer 2011-05-17 16:38:12 UTC
I found two sets of ResourceTypes affected by this problem:

1) AS5 plugin deployments (EARs, WARs, EJB-JARs, etc.)
2) AS4 and AS5 plugin Scripts

With [master 25e909e], I upgraded the keys, using the new resource upgrade facet, as follows:

1) old key format: "vfszip:/C:/opt/jboss-6.0.0.Final/server/default/deploy/http-invoker.sar/invoker.war/" (the ManagedDeployment name)
   new key format: "{default}http-invoker.sar/invoker.war" (where "default" is the profile the deployment is deployed to and the rest is the hierarchy of the managed deployment, using the simple/base names for each of the ancestors

2) old key format: "/opt/jboss/bin/run.sh" (absolute path of script) 
   new key format: "run.sh" if script is under server bin dir, or absolute path otherwise

Comment 5 Larry O'Leary 2011-05-17 17:51:20 UTC
The new key format will not address 1) as described by this bug.

   etat.ear (Node1) Resource Key:
vfsfile:/opt/jboss/eap/jboss-eap-5.1/jboss-as/server/Node1/deploy/etat.ear/
   etat.ear (Node2) Resource Key:
vfsfile:/opt/jboss/eap/jboss-eap-5.1/jboss-as/server/Node2/deploy/etat.ear/



As we can see, the configuration name here is Node1 and Node2. So, this cluster would still uniquely identify the two etat.ear files as separate from a group perspective.

Not sure that this can easily be addressed though unless we look at partition names and group addresses as part of the grouping mechanism. 

This same issue would also apply in the following scenario:

   etat.ear (MyServer) Resource Key:
vfsfile:/opt/jboss/eap/jboss-eap-5.1/jboss-as/server/MyServer/deploy/etat.ear/
   etat.ear (MyServer) Resource Key:
vfsfile:/opt/jboss/eap/jboss-eap-5.1/jboss-as/server/MyServer/customer-apps/etat.ear/

Comment 6 Ian Springer 2011-05-17 19:39:34 UTC
Note, the management profile name used in the new resource key format is not the same thing as the configuration set name (e.g. Node1, Node2). I think the profile name would typically be the same for two nodes in a cluster, so I think the new format will address your use case.

Comment 7 Sunil Kondkar 2011-05-26 09:05:21 UTC
Verified on build101 (Version: 4.1.0-SNAPSHOT Build Number: 712d0e1)

Insalled and imported two JBoss EAP 5 instances into inventory which uses two different configuration directories(default and all).
Created a compatible group of these two instances. Navigated to the Inventory->members tab of admin-console.war application in the group view. Added a 'key' column on the page.

The key for both the resources is displayed as per the new format:  {default}admin-console.war

The key for the script is displayed as as per the new format:  run.sh

Please refer the attached screenshots.

Marking as verified.

Comment 8 Sunil Kondkar 2011-05-26 09:07:21 UTC
Created attachment 501026 [details]
Screenshot_admin-console.war

Comment 9 Sunil Kondkar 2011-05-26 09:08:38 UTC
Created attachment 501027 [details]
Screenshot_run.sh

Comment 11 Heiko W. Rupp 2013-09-03 16:59:27 UTC
Bulk closing of old issues that are in VERIFIED state.

Comment 12 Lukas Krejci 2013-11-15 13:50:25 UTC
*** Bug 601194 has been marked as a duplicate of this bug. ***


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