When resources are uninventoried the resources are marked deleted and later removed in an async way. In the time between the uninventory and the async delete a dynagroup calculation will still include the resource if it matches all of the dgroup criteria.
This is a problem but really, the Dynagroup isn't dynamic at all because even if the recalc was fixed the "doomed" resources would still be in the group until the recalc takes place or the bulk delete runs. The same is true for static groups.
This is a long way of saying that resource uninventory should perform group removal in-band, not async. It will slow down uninventory but will give us a more coherent experience. Otherwise scripts and gui views that deal with groups may see the logically uninventoried resources, unless care is taken to ensure the InventoryStatus is correct.
In short, I think most people, especially script writers, would assume that group members are COMMITTED (they can't be NEW or IGNORED). They would not know about our behind the scenes status.
I'm marking this severity "high" only because I think that, although unlikely to be noticed or be big problem, it could feasibly be very confusing and/or a big problem.
As an example of both the group membership lag, and the dgroup recalc issue:
1) create a dgroup with members that you don't mind uninventorying
2) go to the resource browser and uninventory the resources
3) go look (fairly quickly) at the dgroup membership, it is unchanged. (problem 1)
4) recalc the dgroup. Still unchanged. (problem 2)
Problem 2 is a no-op if we fix problem 1.
dgroup issue root cause analysis:
GroupDefinitionManagerBean.calculateGroupMembership_helper calls out to ResourceManager.findExplicitResourceIdsByResourceGroup
idsToAdd are calcuated as set(calculationResults) minus set(existingResources)
idsToRemove as set(existingResources) minus set(calculationResults)
In this case, the existingResources method is returning an incorrect results. instead of returning ANY resource in the group, it's only returning resources that are COMMITTED.
Looking at commit history for ResourceManager, we learn the findExplicitResourceIdsByResourceGroup method added that COMMITTED filter recently:
Author: Ian Springer <email@example.com> Thu Aug 27 15:50:00 2009
Committer: Ian Springer <firstname.lastname@example.org> Thu Aug 27 15:50:00 2009
fix so nav tree doesn't throw NPE when viewing a compat group with a member that was just uninventoried (http://jira.rhq-project.org/browse/RHQ-2219)
So, the correct fix for all of the aforementioned issues is multi-part:
a) when something is uninventoried, the in-band processor needs to remove it from any and all groups it's in. since that occurs atomically within a transaction, we will guarantee that only COMMITTED resources remain in any group
b) modify findExplicitResourceIdsByResourceGroup and remove the COMMITTED filter. it was added to correct a UI visibility issue which will no longer be an issue once (a) is put into the codebase.
As a consequence of implementing (a), the dgroup issue will automatically be resolved.
Author: Joseph Marques <email@example.com>
Date: Mon Jun 14 17:15:02 2010 -0400
BZ-603187: remove resources from containing groups when they are uninventoried
Verified on JON 2.4 GA_QA build
Created a dynagroup with members. After uninventory of the resource from resource browser, the dynagroup member resource is removed from the group members list.
Mass-closure of verified bugs against JON.