Bug 535586 - (RHQ-2266) dynagroups: add ability to search up more levels of the ancestry
dynagroups: add ability to search up more levels of the ancestry
Status: CLOSED NEXTRELEASE
Product: RHQ Project
Classification: Other
Component: Core Server (Show other bugs)
unspecified
All All
medium Severity medium (vote)
: ---
: ---
Assigned To: Joseph Marques
Jeff Weiss
http://jira.rhq-project.org/browse/RH...
: Improvement
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-24 01:41 EDT by Joseph Marques
Modified: 2014-11-09 17:49 EST (History)
1 user (show)

See Also:
Fixed In Version: 1.3
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
grandparent.png (93.80 KB, image/png)
2009-09-10 10:29 EDT, Jeff Weiss
no flags Details

  None (edit)
Description Joseph Marques 2009-07-24 01:41:00 EDT
today we support "parent" and "grandparent" tokens.
need to support at least two levels above that (great-grandparent and greatgreat-grandparent)

use case is to aggregate the different GCs by name for particular JBossAS servers:

resource.type.name = Garbage Collector // find all GC resources in inventory
resource.type.plugin = JBossAS // which are found under JBoss server
resource.greatGrandParent.name.contains = prod // but only whose JBAS ancestors are in prod
groupby resource.name // create one group for each type ("Copy GC", "MarkSweepCompact GC", etc)
Comment 1 Joseph Marques 2009-07-24 01:43:40 EDT
rev4573 (branch RHQ_1_1_0_GA_CP) - support two additional levels of ancestry-filtering for dynagroups
Comment 2 Charles Crouch 2009-07-30 08:30:30 EDT
greatGrandParent, greatGreatGrandParent is not a scalable solution.

Can we move to something like:

ancestor[1]=parent
ancestor[2]=grandparent
ancestor[3]=greatGrandParent
etc
ancestor[n]

even if its only a semantic change, this is more scalable syntax. 
We don't need to support arbitrary values of n, since that could require fundamental changes to how the backing sql is created.
For a start lets just support upto n=4, since a quick look around a resource hierarchy only shows me resource with up to 4 levels of ancestors.
Comment 3 Charles Crouch 2009-09-01 10:52:31 EDT
Moving features/improvements to 1.4
Comment 4 Charles Crouch 2009-09-01 10:53:20 EDT
Move back to 1.3 if there is time to do this change since we put it in a CP
Comment 5 Joseph Marques 2009-09-03 04:25:39 EDT
rev5090 - support two additional levels of ancestry-filtering for dynagroups: great-grandparent and great-great-grandparent; 

charles: i agree the "great-great" stuff isn't scalable.  however, great-great-grand-parent is now supported, and that searches up 4 levels.  my plan was definitely to do the ancestor[x] deal for this release, but forward-porting the fix took me probably 1/10 the time it would have taken to implement the ancestor fix.  so, let's open a new jira if we still want the ancestor[x] solution, and we can put it on 1.4's plate.
Comment 6 Joseph Marques 2009-09-09 12:02:25 EDT
test procedures are in the description, which includes the exact use case this feature was added for.  also, make sure that "greatgrandparent" and "greatgreatgrandparent" are available in the dynagroup builder/wizard.
Comment 7 Jeff Weiss 2009-09-10 10:29:28 EDT
Tested the case in the description, which worked, see screenshot. rev5122
Comment 8 Red Hat Bugzilla 2009-11-10 16:01:06 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-2266
Imported an attachment (id=368763)

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