JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Cluster Data Services Developer's Guide     Oracle Solaris Cluster 4.1
search filter icon
search icon

Document Information

Preface

1.  Overview of Resource Management

2.  Developing a Data Service

3.  Resource Management API Reference

4.  Modifying a Resource Type

Overview of Modifying a Resource Type

Setting Up the Contents of the Resource Type Registration File

Resource Type Name

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

Changing Monitor Code

Changing Method Code

Determining the Packaging Scheme to Use

Documentation to Provide for a Modified Resource Type

Information About What to Do Before Installing an Upgrade

Information About When to Upgrade Resources

Information About Changes to Resource Properties

5.  Sample Data Service

6.  Data Service Development Library

7.  Designing Resource Types

8.  Sample DSDL Resource Type Implementation

9.  Oracle Solaris Cluster Agent Builder

10.  Generic Data Service

11.  DSDL API Functions

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

E.  CrnpClient.java Application

Index

Determining Installation Requirements and Packaging

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

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

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.