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 of the examples use the following assumptions:
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 appropriate scswitch(1M) command or equivalent. The following example shows moving 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> |
Registration is performed using the equivalent of:
scrgadm -a -t <resource type> -f <path to RTR file> |
Migration is performed using the equivalent of:
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 Resource Type Upgrade Examples
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.
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. |
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 made to the RTR file. |
N/A; no changes to RTR file |
Overwrite the previous versions of the methods. |
Because there were no changes to the RTR file, the resource does not need to be registered or migrated. |