Upgrading a Resource Type
This chapter discusses the issues that you need to understand to upgrade a resource type and migrate a resource.
Overview
System administrators require the ability to install and register a new version of an existing resource type, to allow the registration of multiple versions of a given resource type, and to migrate an existing resource to a new version of the resource type without having to delete and recreate the resource. Resource developers need to understand the requirements for providing resource type upgrade and resource migration.
Resource types developed with upgrade in mind are called upgrade aware.
A new version of a resource type can differ from a previous version in several ways:
Attributes of resource type properties may change
The set of declared resource properties, including standard and extension properties, may change
Attributes of resource properties, such as default, min, max, arraymin, arraymax or tunability may change
The set of declared methods may differ
The implementation of methods or monitors may change.
The resource type developer decides when an existing resource can be migrated to a new version from among the following tunability options. The options are listed from least restrictive to most restrictive:
Any time (Anytime)
When the resource is unmonitored (When_unmonitored)
When the resource is offline (When_offline)
When the resource is disabled (When_disabled)
When the resource group is unmanaged (When_unmanaged)
At creation (At_creation)
Note - Throughout this chapter, the scrgadm command is used when discussing how to do an upgrade. The administrator is not restricted to using the scrgadm command but can also use the GUI or the scsetup command to do the upgrade.
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 registered prior to Sun Cluster 3.1 continue to use the form:
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).