Determining Installation Requirements and Packaging

Keep the following two requirements in mind when determining installation requirements and packaging for resource type packages:

When a new resource type is registered, its RTR file must be accessible on disk.
When a resource of the new type is created, all declared method path names and the monitor program for the new type must be on disk and be executable. The old method and monitor programs must remain in place as long as the resource is in use.

To determine the correct packaging to use, consider the following questions:

Does the RTR file change?
Does the default value or tunability of a property change?
Does the min or max value of a property change?
Does the upgrade add or delete properties?
Does the monitor code change?
Does the method code change?
Are the new methods, the monitor code, or both compatible with the previous versions?

The answers to these questions will help you determine the correct packaging to use for your new resource type.

Before You Change the RTR File

You do not necessarily need to create new method or monitor code when you modify a resource type. For example, you might only change the default value or tunability of a resource property. In this instance, because you do not change the method code, you only require a new valid path name to a readable RTR file.

If you do not need to reregister the old resource type, the new RTR file can overwrite the previous version. Otherwise, place the new RTR file in a new path.

If the upgrade changes the default value or tunability of a property, use the Validate method for the new version of the resource type to verify that the existing property attributes are valid for the new resource type. If they are not, the cluster administrator can change the properties of an existing resource to the correct values. If the upgrade changes the min, max, or type attributes of a property, the clresourcetype(1CL) command automatically validates these constraints when the cluster administrator upgrades the resource type.

If the upgrade adds a new property or deletes an old property, you probably need to change callback methods or monitor code.

Changing Monitor Code

If you change only the monitor code for a resource type, the package installation can overwrite the monitor binaries.

Changing Method Code

If you change only the method code in a resource type, you must determine whether the new method code is compatible with the old method code. The answer to this question determines whether the new method code must be stored in a new path or whether the old methods can be overwritten.

If you can apply the new Stop, Postnet_stop, and Fini methods (if declared) to resources that were initialized or started by the old versions of the Start, Prenet_stop, or Init methods, the old methods can be overwritten with the new methods.

If applying a new default value to a property causes a method such as Stop, Postnet_stop, or Fini to fail, the cluster administrator must accordingly restrict the state of the resource when the resource type is upgraded.

You enable the cluster administrator to restrict the state of the resource when it is upgraded by limiting the tunability of the Type_version property.

One approach to packaging is to include all earlier versions of a resource type that are still supported in the package. This approach permits the new version of a package to replace the old version of the package, without overwriting or deleting the old paths to the methods. You must decide the number of previous versions to support.

Determining the Packaging Scheme to Use

The following table summarizes the packaging schemes to use for your new resource types.

Table 4-1 Determining the Packaging Scheme to Use

Type of Change	Tunability Value	Packaging Scheme
Make property changes in only the RTR file.	`ANYTIME`	Deliver only new RTR file.
Update the methods.	`ANYTIME`	Place the updated methods in a different path than the old methods.
Install the new monitor program.	`WHEN_UNMONITORED`	Overwrite only the previous version of the monitor.
Update the methods. The new `Update` and `Stop` methods are incompatible with the old `Start` methods.	`WHEN_OFFLINE`	Place the updated methods in a different path than the old methods.
Update the methods and add new properties to the RTR file. The new methods require new properties. The goal is to allow the containing resource group to remain online but prevent the resource from coming online if the resource group moves from the offline state to the online state on a node.	`WHEN_DISABLED`	Overwrite the previous versions of the methods.
Update the methods and add new properties to the RTR file. New methods do not require new properties.	`ANYTIME`	Overwrite the previous versions of the methods.
Update the methods. The new `Fini` method is incompatible with the old `Init` method.	`WHEN_UNMANAGED`	Place the updated methods in a different path than the old methods.
Update the methods. No changes are made to the RTR file.	Not applicable. No changes are made to the RTR file.	Overwrite the previous versions of the methods. Because you made no changes to the RTR file, the resource does not need to be registered or upgraded.

Skip Navigation Links
Exit Print View
	Oracle Solaris Cluster Data Services Developer's Guide Oracle Solaris Cluster 4.1