Bug 865826

Summary: RFE: Enable DynaGroups to be created based on the contents of another group.
Product: [Other] RHQ Project Reporter: Larry O'Leary <loleary>
Component: Resource GroupingAssignee: RHQ Project Maintainer <rhq-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: low Docs Contact:
Priority: urgent    
Version: unspecifiedCC: hrupp, loleary, sappleto
Target Milestone: ---   
Target Release: RHQ 4.7   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: PM-187/PRODMGT-187 Environment:
Last Closed: 2013-09-05 03:58:20 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 832398    

Description Larry O'Leary 2012-10-12 10:30:28 EDT
+++ This bug was initially created as a clone of JBoss ON RFE Bug #832398 +++

Description:

Enhance DynaGroup so they can be created based on the contents of another group.

Description of business problem this is aiming to solve:

The customer has multiple different requests from internal customers e.g. one customer wants an email when jvm goes down, other customer wants an email when pool of their ds is filled up, next customer wants a notification when memory exceeds and so on.

This would help, for example, when you bring on line 200 new jboss nodes. You do not want to be adding all new nodes to a compatible group.

Generally this will make it easier to manage the large number of nodes that this customer has. This will also assist in responding to internal customer requirements without putting extra burden on the operation guys maintain new cli scripts.

Another one idea would be to have a extra feature in an event definition where you can have a expression that says the event should be applied to a particular group or parent group or (set of groups) - that maybe this is a new RFE.

--- Additional comment from jsanda on 2012-07-03 12:53:30 EDT ---

I think that there are two major areas that are impacted. The first being the expression evaluation code that generates and executes the JPQL query. Some investigation is needed to determine what effort is involved to support the additional group filtering. Performance will need to be taken into consideration as well.

The second area is the UI.We need to think about how we want the user to select groups. This would likely involve some changes in group definition view. Then we need to think about what changes might be needed in the expression builder.

I think a day or two of analysis would help better determine the amount of effort involved here.

--- Additional comment from loleary on 2012-07-03 13:53:10 EDT ---

To provide a better explanation of what this feature is/could be:

Think of it as a sub-group of one or more groups*. Normally, a dynamic group is created based on the contents of inventory visible to the user who creates it. This feature should allow the dynamic group to be created based on the contents of another group instead of the entire system inventory. Essentially, the dynamic group inherits its dependent group's contents and the dynamic group's expression is then applied to that contents. So, let's say I have the following resource hierarchy in my RHQ system inventory:
.
|-- Platform A
|   |-- JBoss AS 1
|   |   `-- <child resources>
|   |-- JBoss AS 2
|   |   `-- <child resources>
|   |-- Network Card lo
|   |-- Network Card wlan0
|   `-- Network Card eth0
|-- Platform B
|   |-- JBoss AS 3
|   |   `-- <child resources>
|   |-- JBoss AS 4
|   |   `-- <child resources>
|   |-- Network Card lo
|   `-- Network Card eth0
`-- Platform C
    |-- JBoss AS 5
    |   `-- <child resources>
    |-- JBoss AS 6
    |   `-- <child resources>
    |-- Network Card lo
    `-- Network Card eth0



Now I create a recursive compatible group that contains Platform B and Platform C called Main Group:
.
`-- Main Group
    |-- Platform B
    |   |-- JBoss AS 3
    |   |   `-- <child resources>
    |   |-- JBoss AS 4
    |   |   `-- <child resources>
    |   |-- Network Card lo
    |   `-- Network Card eth0
    `-- Platform C
        |-- JBoss AS 5
        |   `-- <child resources>
        |-- JBoss AS 6
        |   `-- <child resources>
        |-- Network Card lo
        `-- Network Card eth0



But now I want a dynamic group named DynaGroup EAP of EAP servers (non-recursive) from Main Group:
.
`-- DynaGroup EAP
    |-- JBoss AS 3
    |-- JBoss AS 4
    |-- JBoss AS 5
    |-- JBoss AS 6



Now, if later someone added Platform A to Main Group, when DynaGroup EAP was recalculated it would look like:
.
`-- DynaGroup EAP
    |-- JBoss AS 1
    |-- JBoss AS 2
    |-- JBoss AS 3
    |-- JBoss AS 4
    |-- JBoss AS 5
    `-- JBoss AS 6


Now a a new dynagroup could be created based on DynaGroup EAP that perhaps used an expression that would provide a group of the JVM resources for each member of DynaGroup EAP. Again, the advantage being that the dynagroup expression is evaluated based on the contents of DynaGroup EAP and not that of system inventory or the direct content of Main Group.









* Due to Bug 667896 multiple groups may not be possible

--- Additional comment from ccrouch on 2012-07-10 13:56:56 EDT ---

So if we constrain the requirements to:

-no sub groups
-limited to just group definitions 
-limit to a single constraint group

we are basically saying we would support another group definition filter, right? e.g.

root.group.name = myPlatforms

to which you could then add any of the currently supported group definition filters?

Can I get a thumbs up or down on whether we could implement this, and that the impl would be <2wks? I need to get confirmation its at least *possible* in order to give Alan some guidance around which release it could fit into.

--- Additional comment from jshaughn on 2012-07-10 16:47:01 EDT ---


Looking at the queries I think this sort of thing should be doable.  We need to decide a little about how the constraining group(s) get specified, whether it's part of the expression or a separate field.  But we should be able to work it in.  I'll estimate about a week of work.

--- Additional comment from jshaughn on 2012-07-11 10:00:41 EDT ---

This work is not yet scheduled, but basically we want to be able to narrow the resources returned by today's generated queries (see ExpressionEvaluator) by filtering on the specified group(s).

So, for example, if the Group Definition is:


Then today's query would be (this fills in the args with values):

SELECT res.id 
  FROM Resource res  
 WHERE res.resourceType.plugin = 'JBossAS' 
   AND res.resourceType.name = 'JBossAS Server'
   AND res.inventoryStatus = org.rhq.core.domain.resource.InventoryStatus.COMMITTED


Now, if we had a constraining group we'd want, I think:

SELECT res.id 
  FROM Resource res  
  JOIN res.implicitGroups implicitGroup
 WHERE res.resourceType.plugin = 'JBossAS' 
   AND res.resourceType.name = 'JBossAS Server'
   AND res.inventoryStatus = org.rhq.core.domain.resource.InventoryStatus.COMMITTED
   AND implicitGroup.id IN ( 10001 )


Note that this query would support multiple groups, in a disjunctive way. Meaning if the resource were in *any* (not all) of the groups then it would be valid.  If we were to support this feature I think a single group, or this disjunctive approach would be what we want.

Note also that we want to use the implicit, not explicit, membership because the use case most likely will want to narrow by a recursive group.

I'm not exactly sure but I think we'd want to include the constraining groups in the expression in order to more easily work this into the query generation.

So, something like what Charles had in comment:

  root.group.name = myPlatforms

But maybe a little more similar to what we have:

  resource.memberOf = groupName

But maybe not, because it would be unlike other expressions in that we may allow several of these, and also, it would not be valid to say:

  resource.parent.memberOf

Similarly, resource.child and resource.grandParent would be invalid.  

So, I guess i don't know, somehow we want to be able to specify, I think, multiple constraining groups, probably as part of the expression or possibly stored completely separately.

--- Additional comment from loleary on 2012-07-25 14:44:13 EDT ---

In an attempt to summarize what the limitation is and to confirm it matches what the user has requested and guide progress, can you guys let me know if the following is correct?

Dynamic group expression definition will be extended to include a group name expression
    - This will allow a user to limit the resources that can be added to the new dynamic group to the resources in the named resource group
    - The named group in the group expression is limited to user created groups (compatible, mixed, and dynamic)
    - Only one group can be specified per dynamic group definition

Dynamic groups created from another group contain a static membership
    - If Group B is created to include resources from Group A, the members of Group A are simply added as members of Group B
    - If Group B is created to include resources from Group A, and a member is later removed from Group A, that member will continue to be a member of Group B (unless the group is recalculated)

--- Additional comment from jshaughn on 2012-07-25 15:07:01 EDT ---

Larry,

Your summary is correct, especially the key points about membership in your group A and B examples.

In the final solution we would reserve the right to specify the constraining group outside of the group definition expression (but still as part of the group definition).  Also, we may decide it will be OK to allow multiple constraining groups such that the dGroup members could pull from any of them (in essence, the constraint set would be the union of the resources in the specified constraint groups.
Comment 1 Heiko W. Rupp 2013-08-31 06:53:09 EDT
Larry, can we close this one, given Bug 832398 has been implemented and is on_qa ?
Comment 2 Larry O'Leary 2013-09-04 20:31:26 EDT
That is your call. Normally, community BZs are kept separate from down-stream product BZs. This allows cleaner tracking and clearer understanding of what product changes made their way into the community and what community releases they are tied to. For example, 832398 relates to the JBoss ON 3.2 release. When the work was done there it should have been pushed to RHQ master and therefore corresponded to an RHQ release. That RHQ release should appear in this BZs target and go ON_QA for the community to test or confirm this functionality separately from the product release cycles.

That being said, that is not required. If the RHQ project does not require work to be tracked, then this BZ could simply be closed without setting the target or release information.

Perhaps this is something that we need to coordinate with the product team to ensure the upstream BZs are getting created and set according to the upstream release plans? Or if no tracking is necessary, then ensuring that community BZs don't get created in the first place.
Comment 3 Heiko W. Rupp 2013-09-05 03:58:20 EDT
This was already implemented in RHQ 4.7 so closing it now.