Setting Up the Contents of the Resource Type Registration File

This section describes how to set up a resource type registration file.

This section covers the following topics:

• Resource Type Name

• Specifying the #$upgrade and #$upgrade_from Directives

• Changing the RT_version in an RTR File

• Resource Type Names in Previous Versions of Sun Cluster

Resource Type Name

The three components of a resource type name are properties that are specified in the RTR file as vendor-id, resource-type, and rt-version. The clresourcetype(1CL) command inserts the period and the colon delimiters to create the name of the resource type:

vendor-id.resource-type:rt-version

The vendor-id prefix serves to distinguish between two registration files of the same name that different companies provide. To ensure that the vendor-id is unique, use the stock symbol of the company when creating the resource type. The rt-version distinguishes between multiple registered versions (upgrades) of the same base resource type.

You can obtain the fully qualified resource type name by typing the following command:

# scha_resource_get -O Type -R resource-name -G resource-group-name

Resource type names that you registered prior to Sun Cluster 3.1 continue to use this syntax:

vendor-id.resource-type

The format of resource type names is described in Format of Resource Type Names.

Specifying the #$upgrade and #$upgrade_from Directives

To ensure that the resource type that you are modifying is upgrade-aware, include the #$upgrade directive in the resource type's RTR file. After the #$upgrade directive, add zero or more #$upgrade_from directives for each earlier version of the resource type that you want to support.

The #$upgrade and #$upgrade_from directives must appear between the resource type property declarations and the resource declarations sections in the RTR file. See the rt_reg(4) man page.

Example 4–1 #$upgrade_from Directive in an RTR File

#$upgrade_from   "1.1"   WHEN_OFFLINE
#$upgrade_from   "1.2"   WHEN_OFFLINE
#$upgrade_from   "1.3"   WHEN_OFFLINE
#$upgrade_from   "2.0"   WHEN_UNMONITORED
#$upgrade_from   "2.1"   ANYTIME
#$upgrade_from   ""      WHEN_UNMANAGED

The format of the #$upgrade_from directive is as follows:

#$upgrade_from version tunability

version

The RT_version. If any resource type does not have a version, or for versions other than what you defined previously in the RTR file, specify the empty string (“”).

tunability

The conditions under which, or when, the cluster administrator can upgrade the specified RT_version.

Use the following tunability values in the #$upgrade_from directives:

ANYTIME

Use when there are no restrictions on when the cluster administrator can upgrade the resource. The resource can be completely online during the upgrade.

WHEN_UNMONITORED

Use when the new resource type version's methods are as follows:

• The Update, Stop, Monitor_check, and Postnet_stop methods are compatible with the older resource type version's starting methods (Prenet_stop and Start)

• The Fini method is compatible with the Init method of older versions

The cluster administrator must only stop the resource monitor program before upgrading.

WHEN_OFFLINE

Use when the new resource type version's Update, Stop, Monitor_check, or Postnet_stop method is as follows:

• Compatible with the Init method of an older version

• Incompatible with an older resource type version's starting methods (Prenet_stop and Start)

The cluster administrator must take the resource offline before upgrading.

WHEN_DISABLED

Similar to WHEN_OFFLINE. However, the cluster administrator must disable the resource before upgrading.

WHEN_UNMANAGED

Use when the new resource type version's Fini method is incompatible with the Init method of an older version. The cluster administrator must switch the existing resource group to the unmanaged state before upgrading.

If a version of the resource type does not appear in the list of #$upgrade_from directives, the RGM imposes the tunability of WHEN_UNMANAGED to that version by default.

AT_CREATION

Use to prevent existing resources from being upgraded to the new version of the resource type. The cluster administrator must delete and re-create a resource.

Changing the RT_version in an RTR File

You only need to change the RT_version property in an RTR file whenever the contents of the RTR file change. Choose a value for this property that clearly indicates that this version of the resource type is the latest version.

Do not include the following characters in the RT_version string in the RTR file or registration of the resource type fails:

• Space

• Tab

• Slash (/)

• Backslash (\)

• Asterisk (*)

• Question mark (?)

• Comma (,)

• Semicolon (;)

• Left square bracket ([)

• Right square bracket (])

The RT_version property, which is optional in Sun Cluster 3.0, is mandatory starting with the Sun Cluster 3.1 release.

Resource Type Names in Previous Versions of Sun Cluster

Resource type names in Sun Cluster 3.0 do not contain the version suffix, as shown here:

vendor-id.resource-type

The name of a resource type that you registered in Sun Cluster 3.0 retains this syntax in Sun Cluster 3.1 and Sun Cluster 3.2. If you register an RTR file in Sun Cluster 3.1 or Sun Cluster 3.2 that omits the #$upgrade directive, the resource type name also follows this syntax.

The cluster administrator can register RTR files by using the #$upgrade directive or the #$upgrade_from directive in Sun Cluster 3.0. However, upgrading existing resources to new resource types in Sun Cluster 3.0 is not supported.