Default Property Values
The RGM stores all resources such that any property that was not explicitly set by the system administrator (and which was defaulted) is not stored in the resource entry in the CCR (cluster configuration repository). The RGM obtains the default value of a missing resource property from the resource type (or if not defined there, using a system-defined default) when a resource is read in from the CCR. It is this method of storing properties that permits an upgraded resource type to define new properties or new default values for existing properties.
When resource properties are edited, the RGM stores in the CCR the properties that were specified in the edit command.
If an upgraded version of the resource type declares a new default value for a defaulted property, the new default value is inherited by existing resources, even if the property is declared tunable only At_creation or When_disabled. If the application of the new default would cause a method such as Stop or Postnet_stop or Fini to fail, the resource type implementor must accordingly restrict the state of the resource at the time that it is upgraded. This is done by limiting the tunability of the Type_version property.
The new resource type version Validate method can check to make sure that existing property attributes are appropriate. If they are not, the system administrator can edit the properties of an existing resource to appropriate values in the same command that edits the Type_version property to upgrade the resource to the new resource type version.
Note - Resources that were created in Sun Cluster 3.0 do not inherit new default property attributes from the resource type when they are migrated to a later version because their default properties are stored in the CCR.
Resource Type Developer Documentation
The resource type developer must provide documentation with the new resource that provides the following information:
Describe any property additions, changes, or deletions
Describe how to make the properties conform to the new requirements
Call out any new default property attributes
Inform the system administrator that existing resource properties are editable to appropriate values using the same command used to edit the Type_version property to upgrade the resource to the new resource type version
Resource Type Name and Resource Type Monitor Implementations
You can register an upgrade aware resource type in Sun Cluster 3.0, but its name is recorded in the CCR without the version suffix. To run correctly in both Sun Cluster 3.0 and Sun Cluster 3.1, the monitor for this resource type must be able to handle both naming conventions:
vendor_id.resource_name:version vendor_id.resource_name |
The monitor code can determine the proper name to use by running the equivalent of:
scha_resourcetype_get -O RT_VERSION -T VEND.myrt scha_resourcetype_get -O RT_VERSION -T VEND.myrt:vers |
Then compare the output values with vers. Only one of these commands will succeed for a particular value of vers, because it is not possible to register the same version of the resource type twice under two different names.
Application Upgrades
The upgrading of application code is unlike the upgrading of agent code, although some of the issues are similar. An application upgrade might or might not be accompanied by a resource type upgrade.
Resource Type Upgrade Examples
These examples illustrate several different resource type installation and upgrade scenarios. Tunability and packaging information have been chosen based on the types of changes made to the resource type implementation. Tunability applies to the migration of the resource to the new resource type.
All examples assume that:
The resource type is delivered in a Solaris-style package. See pkgadd(1M) and pkgrm(1M).
There is only one previous version of the resource type and, therefore, only one #$upgrade_from directive in the new RTR file
The installation procedure will not remove or overwrite the methods if it is possible that the RGM could call the methods while they are removed from the disk
New methods are compatible with old methods unless otherwise stated
Resources and resource groups are moved to the required state before installation or migration using the correct scswitch(1M) command or equivalent. The following example shows how to move the resource group to an unmanaged state:
scswitch -M -n -j resource scswitch -n -j resource scswitch -F -g resource_group scswitch -u -g resource_group
You register a resource type by using this command:
scrgadm -a -t resource_type -f path_to_RTR_file
You migrate a resource by using this command:
scrgadm -c -j resource -y Type_version=version \ -y property=value \ -x property=value ...Resources and resource groups are restored to their previous state after migration using the appropriate scswitch(1M) command or equivalent:
scswitch -M -e -j resource scswitch -e -j resource scswitch -o -g resource_group scswitch -Z -g resource_group
The resource type developer might need to specify more restrictive tunability values than the ones used in these examples. The tunability values depend on the exact changes made to the resource type implementation. Also, the resource type developer might choose to use a different packaging scheme in place of the Solaris-style packaging used in these examples.
Table 3-1 Examples of Upgrading a Resource Type
Type of change | Tunability | Packaging | Procedure |
|---|---|---|---|
Property changes are only made in the RTR file. | Anytime | Only deliver new RTR file. | Do a pkgadd of the new RTR file on all nodes. Register the new resource type. Migrate the resource. |
Methods are updated. | Anytime | Place the updated methods in a distinct path from the old methods. | Do a pkgadd of the updated methods on all nodes. Register the new resource type. Migrate the resource. |
New monitor program. | When_unmonitored | Only overwrite the previous version of the monitor. | Disable monitoring. Do a pkgadd of the new monitor program on all nodes. Register the new resource type. Migrate the resource. Enable monitoring. |
Methods are updated. The new Update/Stop methods are incompatible with the old Start methods. | When_offline | Place the updated methods in a distinct path from the old methods. | Do a pkgadd of the updated methods on all nodes. Register the new resource type. Take the resource offline. Migrate the resource. Bring the resource online. |
Methods are updated and new properties are added to the RTR file. The new methods require new properties. (The goal is to allow the containing resource group to remain online but to prevent the resource from coming online should the resource group move from the offline state to the online state on a node.) | When_disabled | Overwrite the previous versions of the methods. | Disable the resource. For each node:
Register the new resource type. Migrate the resource. Enable the resource. |
Methods are updated and new properties are added to the RTR file. New methods do not require new properties. | Anytime | Overwrite the previous versions of the methods. | For each node:
During this procedure, the RGM will call the new methods even though migration (which would configure the new properties) has not yet been performed. It is important that the new methods be able to work without the new properties. Register the new resource type. Migrate the resource. |
Methods are updated. The new Fini method is incompatible with the old Init method. | When_unmanaged | Place the updated methods in a distinct path from the old methods. | Make the containing resource group unmanaged. Do a pkgadd of the updated methods on all nodes. Register the resource type. Migrate the resource. Make the containing resource group managed. |
Methods are updated. No changes are made to the RTR file. | Not applicable. No changes are made to RTR file | Overwrite the previous versions of the methods. | For each node:
Because there were no changes to the RTR file, the resource does not need to be registered or migrated. |