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(a)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(a)lists.fedorahosted.org
>>
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel