Group Definitions & Dynamic Groups (Dynagroups)

This is a new set of features in JON 2.0 that attempts to further automate the management of inventories, especially large ones.

Introduction

A group definition is a rich, expressive "short-hand" for resource groups. At a high-level, a definition tells the system how to create a group; the details are handled by specifying a list of rules that tell the system how to find and aggregate the appropriate resources to add as members of the group.

Think of all the ways you might want to group resources in an enterprise: by cluster identifier, by broadcast group or some other network-level means, by logical service layer, by geographical location, by security domain, e.t.c.

Any individual resource may fall into multiple "buckets", and thus could potentially be a member of multiple groups. However this becomes a problem and more evident in large inventories. Do you really want to spend hours and hours creating hundreds of groups for thousands of resources across dozens of attributes?

It might not seem so bad if you only had to do it once, but nowadays enterprises are changing every day. Machines are stood up, reach an end of life, re-purposed or upgraded (hardware or software). With enterprises changing so rapidly, who really has the time to sit and make sure all of the hundreds of resource groups have accurate memberships?

Whereas in JON 1.x you had to create and populate all of your compatible and mixed groups, now you can leverage group definitions to do that tedious work for you. So what exactly can you do with this rich, expressive short-hand?

Subsystem Integrations

This section describes all the different attributes of a resource that you can leverage to write your definition. Please note that this section does not describe how to use group definitions (this is discussed later in this chapter). This section can serve as a quick reference for the terms that are supported when building up expressions.

Syntax References

<group-definition>        = { <expression> } ;
<expression>              = ( <simple-expression> | <pivoted-expression> | <narrowing-expression> ) ;
<simple-expression>       = <simple-lhs-expression>, [ <string-match-expression> ], "=", <value-expression> ;
<simple-lhs-expression>   = <resource-expression> ;
<value-expression>        = ? all visible characters ? ;
<pivoted-expression>      = "groupby" <simple-lhs-expression> ;
<string-match-expression> = ".", ( "startsWith" | "endsWith" | "contains" ) ;

<resource-expression>     = "resource.",
                            ( <parent-expression> | <grand-parent-expression> | <resource-attributes-expression> ) ;
<parent-expression>       = "parent.", <resource-attributes-expression> ;
<grand-parent-expression> = "grandParent.", <resource-attributes-expression> ;

<resource-attributes-expression>      = "id" | "name" | "version" | <resource-type-expression> |
                                         <configuration-expression> | <measurement-expression> ;
<resource-type-expression>            = "type.", <resource-type-attributes-expression> ;
<resource-type-attributes-expression> = "plugin" | "name" | "category" ;

<configuration-expression> = ( "pluginConfiguration" | "resourceConfiguration" ), <property-expression> ;
<measurement-expression> = "trait", <property-expression> ;

<property-expression> = "[", <property-name>, "]" ;
<property-name>       = { <alpha-numeric-character> + "-" + "." } ;



<narrowing-expression> = "memberof =" <group-name>"

resource.name
resource.version
resource.type.plugin
resource.type.name
resource.type.category

resource.parent.id
resource.parent.name
resource.parent.version
resource.parent.type.plugin
resource.parent.type.name
resource.parent.type.category

resource.grandParent.id
resource.grandParent.name
resource.grandParent.version
resource.grandParent.type.plugin
resource.grandParent.type.name
resource.grandParent.type.category

resource.pluginConfiguration
resource.resourceConfiguration

resource.trait

A Not-So-Short Tutorial

In each "unrolled" case above, the expression could have taken on one of two types - a pivoted expression, or a simple expression. A simple expression requires that you specify exactly one value that the expression must match. An example of this would be:resource.parent.type.category = Platform
This means that you want to search your entire inventory and find any resources that have a parent which happens to be a platform. In other words, you intend to create a single group, and put all of the direct children resources of any platform in your inventory into it. You can also take a further step and add another filter to the one above:resource.parent.type.category = Platform
resource.name.contains = JBossAS
This compound expression (each part of which must be on a separate line) will now search the entire inventory as above, but this time it will only add resources to the group if they also have "JBossAS" anywhere in their name.

Unfortunately for large inventories, this would almost certainly create a group with a very large membership. So, from a practical standpoint, it starts to lose its luster. Luckily, we still have a few tricks up our group definition sleeves...

Pivoted expressions are where the real power of group definitions shines through. Their features are described below. As an example, if we had a pivoted expression like:groupby resource.parent.name
The above expression would first take the portion after the "groupby" text, and ask the inventory for ALL unique "resource.parent.name" results. In other words, it is going to find one result for each uniquely named resource in the system, as long as that resource has one or more children resources. For each unique result, it would create one group, and put any resource into it that matched that criteria.

So let's say our inventory looked like:

• ResourceParentA

  • ResourceChildA1

  • ResourceChildA2

    • ResourceGrandChildA2a

    • ResourceGrandChildA2b

  • ResourceChildA3

• ResourceParentB

  • ResourceChildB1

  • ResourceChildB2

  • ResourceChildB3

  • ResourceChildB4

The first part of the expression would find all the unique names of the parent resources, in this case:

• ResourceParentA (which has 3 direct children)

• ResourceChildA2 (which has 2 direct children, which are the grandchildren of its parent)

• ResourceParentB (which has 4 direct children)

Then, it will create one group for each of them, and populate them as necessary to satisfy the expression. The group members would be as follows:

With only a few characters we have now automated the creation of three groups (but this would be more in larger inventories), and the memberships of those groups (which, again, in this case was small, but would normally be on the order of dozens).

The above is only an introduction to pivoted expressions. JBoss ON also supports compound pivoted expressions, which look very similar to the compound simple expression discussed at the beginning of this tutorial. An example of a compound pivoted expression might be:

groupby resource.type.plugin
groupby resource.type.name
groupby resource.parent.name

The "groupby" text is required in the front of each expression that you want to make a pivot. This compound expression creates a compatible group - since we know that the members of a compatible group all have the same type, we've pivoted on both the plugin that defined the type as well as the type name itself to ensure that we will automatically get one group for each unique type currently known to the system.

And if that wasn't powerful enough we took the pivot concept one step further. Instead of having one gigantic compatible group of, say, EJB3 Session Beans across your entire enterprise, we are also pivoting on the parent. We will therefore get one group for each collection of Session Beans that share the same parent.

As you can see, pivoted expressions give us the ability to create extremely fine-grained, automatically managed, divisions of our resources. For a small inventory, this is handy tool; for a large inventory, this is a priceless tool.

And if that weren't enough, we also support the mixing and matching of pivoted and non-pivoted expressions in the same group definition. Let's use our last example, but filter the results even more precisely as follows:

resource.type.category = server
groupby resource.type.plugin
groupby resource.type.name
groupby resource.parent.name

This compound, mixed expression would constrain the search a bit. Instead of creating one compatible group for every single resource type known in the system, it would only create compatible groups for every unique resource type that is also a server.

Hints, Tip, & Tricks

exprA1
exprA2
groupby exprB1
groupby exprB2
exprA2
exprA1
groupby exprB2
groupby exprB1

exprA1
groupby exprB1
groupby exprB1
exprA1

exprA1
exprA2

exprB

Examples

resource.type.plugin = JBossAS
resource.type.name = JBossAS Server
groupby resource.trait[partitionName]

resource.type.plugin = Platforms
resource.type.category = PLATFORM
groupby resource.type.name

groupby resource.type.plugin
groupby resource.type.name
groupby resource.parent.name

resource.type.plugin= Postgres
resource.type.name = Table
resource.parent.name = rhq Database
resource.name.contains = rhq_meas_data_num_

resource.type.plugin= RHQAgent
resource.type.name = RHQ Agent
resource.resourceConfiguration[rhq.communications.multicast-detector.enabled] = true

resource.type.plugin= Platforms
resource.type.name = Windows
resource.pluginConfiguration[eventTrackingEnabled] = true

groupby resource.parent.trait[Trait.hostname]
resource.type.plugin = JBossAS
resource.type.name = JBossAS Server

resource.type.plugin = JBossAS7
resource.type.category = SERVER
resource.parent.type.category = PLATFORM
groupby resource.pluginConfiguration[productType]
groupby resource.type.name

resource.type.plugin = JBossAS7
resource.type.category = SERVER
resource.parent.type.category = PLATFORM
groupby resource.pluginConfiguration[productType]
groupby resource.type.name