Red Hat Bugzilla – Full Text Bug Listing
|Summary:||[as4] Script resources not clustered in a recursive compatible group of servers|
|Product:||[Other] RHQ Project||Reporter:||Lukas Krejci <lkrejci>|
|Component:||Plugins||Assignee:||Lukas Krejci <lkrejci>|
|Status:||CLOSED DUPLICATE||QA Contact:||Mike Foley <mfoley>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-11-15 08:50:25 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Lukas Krejci 2010-06-07 08:54:35 EDT
Description of problem: In a recursive compatible group, child resources of group members are "clustered" together using the resource key. This enables the user to have a quick overview of stuff common in all the group members. Script resources have resource keys composed of the absolute path to the script file, which makes them impossible to be clustered, because the resource key will be different for each. This is technically not much of a problem, more so if we realize that the name of the file doesn't tell much about it true contents, but from usability point of view, this could be improved. The solution would be to make the resource key file paths relative from $JBOSS_HOME. How reproducible: always Steps to Reproduce: 1. Inventory 2 JBoss AS4 instances 2. Create a recursive compatible group of JBoss AS Server type and add the 2 resources to it. 3. Observe that there are 2 scripts resources of the same name for each script that happens to be in both of the server instances. Actual results: Each script resource is always represented as a standalone entry in the group tree. Expected results: The scripts should be clustered together by their file name.
Comment 1 Larry O'Leary 2011-03-28 12:29:12 EDT
This issue isn't only limited to scripts, but also to any resource which uses a path as part of its resource key. For example, in AS5 EARs, WARs, and EJBs get a key name of vfsfile:/path/to/deployment. This logic creates two problems: 1) What if the deployment (script, EAR, WAR, etc) just happens to have the same name? 2) What if one of the AS instances is running the Node1 profile and the other is running the Node2 profile? Not sure there is much we can do about 1). This is high-risk to assume that just because the name is the same, they are the same. We should probably warn about this somehow in our documentation if we don't already. For 2), the issue is very common. Each AS instance is started using a unique profile name to distinguish which server/node the instance represents. In the case that two different profile names are used, the same EAR deployed to a cluster will be seen as two different EARs: 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/ The same thing applies to scripts. The suggested solution would not resolve this issue. It would only resolve the use-case in which JBOSS_HOME may be different on each instance. It does not take into account that each instance could be using a unique configuration/profile. I have logged Bug 691476 to capture the resource key uniqueness issue.