Sun Cluster 3.1 10/03 Data Services Developer's Guide

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: Take the node out of the cluster Do a `pkgrm`/`pkgadd` of the methods being updated Restore the node to the cluster 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: Take the node out of the cluster Do a `pkgrm`/`pkgadd` of the methods being updated Restore the node to the cluster 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: Take the node out of the cluster Do a `pkgadd` of the updated methods Restore the node to the cluster. Because there were no changes to the RTR file, the resource does not need to be registered or migrated.