Bug 603187 - Group removal for an uninventoried resource should not be deferred to bulk delete
Group removal for an uninventoried resource should not be deferred to bulk de...
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Resource Grouping (Show other bugs)
1.3.1
All All
medium Severity high (vote)
: ---
: ---
Assigned To: Joseph Marques
Corey Welton
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-11 15:31 EDT by Jay Shaughnessy
Modified: 2010-08-12 12:48 EDT (History)
2 users (show)

See Also:
Fixed In Version: 2.4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-12 12:48:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jay Shaughnessy 2010-06-11 15:31:24 EDT
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.
Comment 1 Jay Shaughnessy 2010-06-11 15:33:50 EDT
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.
Comment 2 Joseph Marques 2010-06-11 15:48:02 EDT
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:

commit 2721214d83f5c099c9d10798caeb637fe47d7270
Author:	Ian Springer <ispringe@redhat.com>  Thu Aug 27 15:50:00 2009
Committer:	Ian Springer <ispringe@redhat.com>  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.
Comment 4 Joseph Marques 2010-06-14 17:17:51 EDT
commit 6a37f3e3ecd936b75944958b5d65688af08f20b8
Author: Joseph Marques <joseph@redhat.com>
Date:   Mon Jun 14 17:15:02 2010 -0400

    BZ-603187: remove resources from containing groups when they are uninventoried
Comment 5 Sunil Kondkar 2010-06-23 04:38:30 EDT
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.
Comment 6 Corey Welton 2010-08-12 12:48:26 EDT
Mass-closure of verified bugs against JON.

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