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

Search Scope:

- This Document
- Entire Library

## Setting Up the Contents of the Resource Type Registration File

This section describes how to set up a resource type registration file.

This section covers the following topics:

- Resource Type Name

- Specifying the `#$upgrade` and `#$upgrade_from` Directives

- Changing the `RT_version` in an RTR File

### Resource Type Name

The three components of a resource type name are properties that are specified in the RTR file as vendor-id, resource-type, and rt-version. The `clresourcetype`(1CL) command inserts the period and the colon delimiters to create the name of the resource type:

    vendor-id.resource-type:rt-version

The vendor-id prefix serves to distinguish between two registration files of the same name that different companies provide. To ensure that the vendor-id is unique, use the stock symbol of the company when creating the resource type. The rt-version distinguishes between multiple registered versions (upgrades) of the same base resource type.

You can obtain the fully qualified resource type name by typing the following command:

    # scha_resource_get -O Type -R resource-name -G resource-group-name

The format of resource type names is described in Format of Resource Type Names.

### Specifying the `#$upgrade` and `#$upgrade_from` Directives

Existing resources can be upgraded at run time to a new upgrade-aware version of their resource type. However, if the new resource type version is non-upgrade-aware, you would have to delete and recreate any existing resources of that type to move them to the new version. Therefore, new resource types should always include the `#$upgrade` directive.

To ensure that the resource type that you are modifying is upgrade-aware, include the `#$upgrade` directive in the resource type's RTR file. After the `#$upgrade` directive, add zero or more `#$upgrade_from` directives for each earlier version of the resource type that you want to support.

The `#$upgrade` and `#$upgrade_from` directives must appear between the resource type property declarations and the resource declarations sections in the RTR file. See the `rt_reg`(4) man page.

Example 4-1 `#$upgrade_from` Directive in an RTR File

    #$upgrade
    #$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

The format of the `#$upgrade_from` directive is as follows:

    #$upgrade_from version tunability

version

  The `RT_version`. If any resource type does not have a version, or for versions other than what you defined previously in the RTR file, specify the empty string (“”).

tunability

  The conditions under which, or when, the cluster administrator can upgrade the specified `RT_version`.

  Use the following tunability values in the `#$upgrade_from` directives:

  `ANYTIME`

    Use when there are no restrictions on when the cluster administrator can upgrade the resource. The resource can be completely online during the upgrade.

  `WHEN_UNMONITORED`

    Use when the new resource type version's methods are as follows:

    - The `Update`, `Stop`, `Monitor_check`, and `Postnet_stop` methods are compatible with the older resource type version's starting methods (`Prenet_stop` and `Start`)

    - The `Fini` method is compatible with the `Init` method of older versions

    The cluster administrator must only stop the resource monitor program before upgrading.

  `WHEN_OFFLINE`

    Use when the new resource type version's `Update`, `Stop`, `Monitor_check`, or `Postnet_stop` method is as follows:

    - Compatible with the `Init` method of an older version

    - Incompatible with an older resource type version's starting methods (`Prenet_stop` and `Start`)

    The cluster administrator must take the resource offline before upgrading.

  `WHEN_DISABLED`

    Similar to `WHEN_OFFLINE`. However, the cluster administrator must disable the resource before upgrading.

  `WHEN_UNMANAGED`

    Use when the new resource type version's `Fini` method is incompatible with the `Init` method of an older version. The cluster administrator must switch the existing resource group to the unmanaged state before upgrading.

    If a version of the resource type does not appear in the list of `#$upgrade_from` directives, the RGM imposes the tunability of `WHEN_UNMANAGED` to that version by default.

  `AT_CREATION`

    Use to prevent existing resources from being upgraded to the new version of the resource type. The cluster administrator must delete and recreate a resource.

### Changing the `RT_version` in an RTR File

You only need to change the `RT_version` property in an RTR file whenever the contents of the RTR file change. Choose a value for this property that clearly indicates that this version of the resource type is the latest version.

Do not include the following characters in the `RT_version` string in the RTR file or registration of the resource type fails:

- Space

- Tab

- Slash (`/`)

- Backslash (`\`)

- Asterisk (`*`)

- Question mark (`?`)

- Comma (`,`)

- Semicolon (`;`)

- Left square bracket (`[`)

- Right square bracket (`]`)

The `RT_version` property is required.

Copyright © 2000, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |