Skip Navigation Links | |
Exit Print View | |
Oracle Solaris Cluster Data Services Developer's Guide Oracle Solaris Cluster 3.3 3/13 |
1. Overview of Resource Management
3. Resource Management API Reference
Overview of Modifying a Resource Type
Setting Up the Contents of the Resource Type Registration File
Specifying the #$upgrade and #$upgrade_from Directives
Changing the RT_version in an RTR File
What Happens When a Cluster Administrator Upgrades
Determining Installation Requirements and Packaging
Before You Change the RTR File
Determining the Packaging Scheme to Use
Documentation to Provide for a Modified Resource Type
Information About What to Do Before Installing an Upgrade
6. Data Service Development Library
8. Sample DSDL Resource Type Implementation
9. Oracle Solaris Cluster Agent Builder
12. Cluster Reconfiguration Notification Protocol
13. Security for Data Services
A. Sample Data Service Code Listings
B. DSDL Sample Resource Type Code Listings
C. Requirements for Non-Cluster Aware Applications
D. Document Type Definitions for the CRNP
Instructions that tell the cluster administrator how to upgrade a resource type are provided in Upgrading a Resource Type in Oracle Solaris Cluster Data Services Planning and Administration Guide. To enable the cluster administrator to upgrade a resource type that you modify, supplement these instructions with additional information, as described in this section.
Generally, when you create a new resource type, you need to provide documentation that does the following:
Describes the properties that you add, change, or delete
Describes how to make the properties conform to the new requirements
Calls out any new default property attributes
Informs the cluster administrator that he or she can set existing resource properties to their correct values if necessary
Explain to the cluster administrator what he or she must do before installing the upgrade package on a node, as follows:
If the upgrade package overwrites existing methods, tell the cluster administrator to unmonitor all resources.
If the upgrade package updates only the RTR file, leaving the method and monitor code unchanged, it is not necessary to unmonitor resources.
Explain to the cluster administrator when he or she can upgrade resources to a new version of the resource type.
The conditions under which the cluster administrator can upgrade the resource type depend on the tunability of the #$upgrade_from directive for each version of the resource in the RTR file, as follows:
Any time (ANYTIME)
Only when the resource is unmonitored (WHEN_UNMONITORED)
Only when the resource is offline (WHEN_OFFLINE)
Only when the resource is disabled (WHEN_DISABLED)
Only when the resource group is unmanaged (WHEN_UNMANAGED)
Example 4-2 How #$upgrade_from Defines When a Cluster Administrator Can Upgrade
This example shows how the tunability of the #$upgrade_from directive affects the conditions under which the cluster administrator can upgrade a resource to a new version of a resource type.
#$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
|
Describe any changes that you have made to the resource type that require the cluster administrator to modify properties of existing resources when he or she upgrades.
Possible changes that you can make include the following:
Default settings of existing resource type properties that you have changed
New extension properties of the resource type that you have introduced
Existing properties of the resource type that you have withdrawn
Changes to the set of standard properties that you have declared for the resource type
Attributes of resource properties such as min, max, arraymin, arraymax, default, and tunability that you have changed
Changes to the set of methods that you have declared
Implementation of methods or the fault monitor that you have changed