Resource Type Registration File

Resource Type Name

The three components of the resource type name are properties specified in the RTR file as Vendor_id, Resource_type, and RT_version. The scrgadm 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 provided by different vendors. The RT_version distinguishes between multiple registered versions (upgrades) of the same base resource type. To ensure that the Vendor_id is unique, the recommended approach is to use the stock symbol for the company creating the resource type.

Registration of the resource type will fail if the RT_version string includes a blank, tab, slash (/), backslash (\), asterisk (*), question mark (?), comma (,), semicolon (;), left square bracket ([), or right square bracket (]) character.

The RT_Version property, which was optional in Sun Cluster 3.0, is mandatory starting in Sun Cluster 3.1.

The fully qualified name is the name returned by 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 the syntax:

vendor_id.resource_type

Directives

RTR files for upgrade aware resource types must include a #$upgrade directive, followed by zero or more directives of the form:

#$upgrade_from version tunability

The upgrade_from directive consists of the string #$upgrade_from, followed by the RT_Version, followed by the tunability constraint on the resource. If the resource type from which the upgrade is being performed does not have a version, the RT_Version is specified as the empty string, as shown in the last example below:

#$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 RGM enforces these constraints on a resource when the system administrator attempts to change the resource Type_version. If the current version of the resource type does not appear in the list, the RGM imposes the tunability of When_unmanaged.

These directives must appear between the resource type property declarations section of the RTR file and the resource declarations section of the RTR file. See rt_reg(4).

Changing the RT_Version in an RTR file

Change the RT_Version string in an RTR file whenever the contents of the RTR file changes. The value of this property must make it obvious which is the newer version of the resource type and which is the older. There is no need to change the RT_Version string if there are no changes to the RTR file.

Resource Type Names in Earlier Versions of Sun Cluster

Resource type names in Sun Cluster 3.0 did not contain the version suffix:

vendor_id.resource_name

A resource type that was originally registered under Sun Cluster 3.0 continues to have a name of this form even after you upgrade the clustering software to Sun Cluster 3.1 or later releases. Similarly, a resource type whose RTR file is missing the #$upgrade directive is given a Sun Cluster 3.0 format name, without the version suffix, if the RTR file is registered on a cluster that is running Sun Cluster 3.1 or later software.

You can register RTR files with the #$upgrade or #$upgrade_from directive in Sun Cluster 3.0, but, migrating existing resources to new resource types in Sun Cluster 3.0 is not supported.