IBM Tivoli Monitoring > Version 6.3 Fix Pack 2 > Installation Guides > Installation Guide > Deploy monitoring agents across your environment > Bulk agent deployment > Organizing deployments using groups

IBM Tivoli Monitoring, Version 6.3 Fix Pack 2


Group properties

When using the tacmd command for deployment (createNode, addSystem, etc.), you can use the –p option to specify properties that modify parameters of the deployment or to specify configuration parameters to the agent installation process. When using the command interface with deploy and bundle groups, properties previously specified on the deploy command-line can be attached to the groups themselves or to group members.

Attaching properties to groups and group members means that they are available for reuse each time the group is referenced in a deployment command without your needing to specify properties again on the command-line. This creates a very powerful mechanism for defining behaviors around your deployments and reusing them each time you specify a group as part of a deployment.

When creating your deploy and bundle groups for bulk deployment, you can assign properties to these groups. Properties at the group level apply to all members of the group. Additionally, properties can be assigned to individual group members. Any property assigned to a member applies to that member only and overrides a similar property specified at the group level. This allows you to build a hierarchy of properties that is consolidated during deployments to create a complete deployment request. Properties specified on the groups and group members can include any combination of OS agent, application agent, and deployment properties. See the Command Reference for more information about specific properties.

Consider the following example where you want to deploy the UNIX OS agent to five AIX systems with the following hostnames.

To do this, you must provide login credentials. All five systems share the same root userid and password. When creating the group, you can assign the userid and password to the group so it applies to all members. This way, you need specify the login credentials only once.

By attaching the userid and password to the deploy group at the group level, the properties apply to all members without having to repeat them for each member.

Suppose that one of the systems was on the far side of a slow link and required more time to complete a deployment. By adding a property to that member, you can change the behavior associated with that member without affecting the behavior of the others.

But suppose that one of the members had a different root password. By attaching this password to the member for that system, you override the value at the group level and replace it with the member-specific value.


Table 1 illustrates how the properties from the above example combine to build a useful set of consolidated properties.


Interaction between member properties and group properties

Member Group properties Member properties Consolidated properties
aix1 KDYRemote Execution and Access.Remote Execution and AccessUSERNAME=root KDYRemote Execution and Access.Remote Execution and AccessPASSWORD=mypass   KDYRemote Execution and Access.Remote Execution and AccessUSERNAME=root KDYRemote Execution and Access.Remote Execution and AccessPASSWORD=mypass
aix2 KDYRemote Execution and Access.Remote Execution and AccessUSERNAME=root KDYRemote Execution and Access.Remote Execution and AccessPASSWORD=mypass   KDYRemote Execution and Access.Remote Execution and AccessUSERNAME=root KDYRemote Execution and Access.Remote Execution and AccessPASSWORD=mypass
aix3 KDYRemote Execution and Access.Remote Execution and AccessUSERNAME=root KDYRemote Execution and Access.Remote Execution and AccessPASSWORD=mypass

    KDYRemote Execution and Access
    .TIMEOUT=3600

KDYRemote Execution and Access.Remote Execution and AccessUSERNAME=root KDYRemote Execution and Access.Remote Execution and AccessPASSWORD=mypass KDYRemote Execution and Access.TIMEOUT=3600
aix4 KDYRemote Execution and Access.Remote Execution and AccessUSERNAME=root KDYRemote Execution and Access.Remote Execution and AccessPASSWORD=mypass   KDYRemote Execution and Access.Remote Execution and AccessUSERNAME=root KDYRemote Execution and Access.Remote Execution and AccessPASSWORD=mypass
aix5 KDYRemote Execution and Access.Remote Execution and AccessUSERNAME=root KDYRemote Execution and Access.Remote Execution and AccessPASSWORD=mypass

    KDYRemote Execution and Access
    .Remote Execution and 
    AccessPASSWORD=yourpass

    KDYRemote Execution and 
    Access.Remote Execution 
    and AccessUSERNAME=root
    KDYRemote Execution and 
    Access.Remote Execution 
    and AccessPASSWORD=yourpass

As you can see in the above example, group and member properties are joined during deployment to create a consolidate set of properties that are used for the deployment. Notice, however, that the deploy group member properties take precedence over and can actually override those at the deploy group level. This is visible with aix5.mycompany.com where the member value for KDYRemote Execution and Access.Remote Execution and AccessPASSWORD overrode the group value.

This same property mechanism applies to bundle groups as well. There might be a property that you want to apply to an agent bundle in a group regardless of where they are deployed. In this case you would attach the property to the bundle group. Likewise, you might want to specify a property that applies to a single agent type within a bundle group. In this case you attach the property to the bundle member.

During a deployment operation where you deploy a bundle group to a deploy group, property consolidation occurs across all properties at the group and member level for both groups. Table 2 lays out the precedence of group/member properties.


Property precedence between deploy groups and bundle groups

Precedence Property location What goes here
highest Deploy group members Properties specific to the individual member target.
  Deploy group Properties common to all targets of the group. For example, if agents deployed to every target member of the group will connect to the same remote monitoring server, then you can specify the server's connection properties here.
  Bundle group member Properties common to all deployments of the specific member bundle of the group. For example, if the bundle group contains the DB2 agent for Windows and you want all installations of DB2 agents on Windows to use a specific property, specify it here.
lowest Bundle group Properties common to all deployments of every bundle within the group, regardless of target.


Parent topic:

Organizing deployments using groups

+

Search Tips   |   Advanced Search