Usage of implicitResources in ClusterManagerBean#buildQuery

Jay Shaughnessy jshaughn at redhat.com
Thu Oct 11 18:09:36 UTC 2012


On 10/10/2012 3:06 AM, Andreas Veithen wrote:
> John,
>
> What you are saying makes perfect sense _in general_, but I have a
> doubt about that _particular_ query.
>
> As far as I can see, the code (actually
> ClusterManagerBean#getAutoClusterResources) executing that query gets
> a cluster key as input and is expected to return the corresponding
> resources. In my case, the cluster key refers to a group of WebSphere
> servers and its hierarchy is ("JVM", "java.lang:type=Memory",
> "java.lang:name=MarkSweepCompact,type=GarbageCollector"). If I
> understand the generated query correctly, it searches for resources
> satisfying all of the following conditions:
>
> * The key of the resource is
> 'java.lang:name=MarkSweepCompact,type=GarbageCollector'.
> * The resource key of the parent is 'java.lang:type=Memory '.
> * The resource key of the grandparent is 'JVM'.
> * The grandgrandparent is an implicit member of the group of WebSphere servers.
>
> That makes sense, except for the usage of the implicit membership in
> the last condition. In fact, the grandgrandparent can only be a root
> level member (a WebSphere server in my case), i.e. it is always part
> of the explicit membership. So why does the query use the implicit
> membership? Are there any cases where that condition in the query is
> satisfied by an implicit member that is not an explicit member?

Looking at this I think I agree with you.  The recursive nature of the 
query should guarantee that the group membership check is for the 
top-most ancestor, and therefore an explicit resource of the compatible 
group.  The query looks like it was written like this from day 1, way 
back in 2008, and I'm guessing that since it works no one ever 
questioned it.

>
> There is another way to look at that question: I understand that the
> implicit membership is used in authorization checks, but what does
> ClusterManagerBean#getAutoClusterResources have to do with
> authorization?
That Authorization comment was added later and I agree with you, I don't 
think this has anything to do with authorization. Authorization for 
autoclusters is basically handled by ensuring that the user has access 
to the top level group.  If so, then it is implied that the use can view 
the group members.

Andreas, good investigation work, please submit a Bugzilla and add this 
discussion as a comment.  I'll probably end up taking one more look at 
this and likely make the change.

>
> Andreas
>
> On Tue, Oct 9, 2012 at 5:11 PM, John Mazzitelli <mazz at redhat.com> wrote:
>> Implicit members are used for recursive groups. IIRC, if you have a non-recursive group (doesn't matter if its a mixed group or compatible group), the implicit group membership will be the same as the explicit group membership.
>>
>> If you have a recursive group, it means the members of the group will not only be the resources you explicitly put into the group (hence the name "explicit members") but it also means all of the children of those resources will also be automatically (implicitly) added as members of that group (hence the name "implicit members").
>>
>> Recursive groups are normally only used for authorizing access to its members (hence the comment you see).

Although the authorization use case is a major one, I'm not sure I'd say 
"normally only used" because the recursive compatible group for cluster 
views, like what we're talking about here, is also a major use case when 
looking at "normalized" deployments.

>>   For example, if you want users in the role "app server admins" to have access to your app server resources, you can just create a group of app server resources, make it recursive, and give access to that group to your "app server admins" role. Now the users in that role can access any resource associated with the app servers (including their children resources like datasources, web apps, etc).
>>
>> To perform authorization checks, RHQ checks the implicit resources because if you are a user trying to look at a webapp resource, for example, RHQ needs to not only look at the explicit members of that group but must also see if a group you have access to has that resource in its implicit members as well. So it just checks implicit membership (note: explicit resources are also in the implicit resource list - in other words, the explicit resource list is a subset of the implicit resource list - for non-recursive groups, explicit resource set is the same as the implicit resource set).
>>
>> ----- Original Message -----
>>> ClusterManagerBean#buildQuery contains the following code:
>>>
>>>          // this is an authorization-related query, so use
>>> implicitResource (not explicitResources)
>>>          if (1 == size) {
>>>              query
>>>                  .append("SELECT rgir FROM ResourceGroup rg JOIN
>>> rg.implicitResources rgir WHERE rgir.inventoryStatus = 'COMMITTED'
>>> AND
>>> rg = "
>>>                  + clusterKey.getClusterGroupId());
>>>          } else {
>>>              buildQuery(query, params, clusterKey, nodes.subList(0,
>>>              size - 1));
>>>          }
>>>
>>> We have a situation where the usage of implicitResources instead of
>>> explicitResources appears to cause a performance issue. This occurs
>>> for depth 3 resources related to the JVM (e.g. as JVM > Memory
>>> Subsystem > MarkSweepCompact) in a compatible group. When trying to
>>> open the summary for such a resource, the request times out because
>>> the database takes too much time to complete the query. Note that
>>> other resources at depth 3 are not affected by this problem. My guess
>>> is that this is related to the fact that the keys of the resources in
>>> the hierarchy ('JVM', 'java.lang:type=Memory' and
>>> 'java.lang:name=MarkSweepCompact,type=GarbageCollector' in the
>>> example) for these resources are "less unique" than for other
>>> resources (we have 39 JVMs in the inventory).
>>>
>>> I tested the problematic database query, and if I replace
>>> RHQ_RESOURCE_GROUP_RES_IMP_MAP by RHQ_RESOURCE_GROUP_RES_EXP_MAP,
>>> then
>>> it returns the same results, but much faster. Therefore I would like
>>> to understand the meaning of the comment "this is an
>>> authorization-related query, so use implicitResource (not
>>> explicitResources)". Can somebody explain that to me?
>>>
>>> Andreas
>>>
>>> PS: I've investigated this with RHQ 4.5.1, but 3.0.0 had the same
>>> problem.
>>> _______________________________________________
>>> rhq-devel mailing list
>>> rhq-devel at lists.fedorahosted.org
>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>>>
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel




More information about the rhq-devel mailing list