+++ 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.