Bug 535586 (RHQ-2266)

Summary: dynagroups: add ability to search up more levels of the ancestry
Product: [Other] RHQ Project Reporter: Joseph Marques <jmarques>
Component: Core ServerAssignee: Joseph Marques <jmarques>
Status: CLOSED NEXTRELEASE QA Contact: Jeff Weiss <jweiss>
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: dajohnso
Target Milestone: ---Keywords: Improvement
Target Release: ---   
Hardware: All   
OS: All   
URL: http://jira.rhq-project.org/browse/RHQ-2266
Whiteboard:
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: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
grandparent.png none

Description Joseph Marques 2009-07-24 05:41:00 UTC
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 05:43:40 UTC
rev4573 (branch RHQ_1_1_0_GA_CP) - support two additional levels of ancestry-filtering for dynagroups

Comment 2 Charles Crouch 2009-07-30 12:30:30 UTC
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 14:52:31 UTC
Moving features/improvements to 1.4

Comment 4 Charles Crouch 2009-09-01 14:53:20 UTC
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 08:25:39 UTC
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 16:02:25 UTC
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 14:29:28 UTC
Tested the case in the description, which worked, see screenshot. rev5122

Comment 8 Red Hat Bugzilla 2009-11-10 21:01:06 UTC
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-2266
Imported an attachment (id=368763)