Using Subclassed GDSv2 Resource Types

Language:

This section contains information about subclassing a GDSv2 resource type.

Reasons to Subclass GDSv2 Resource Types

When using a resource of type ORCL.gds or ORCL.gds_proxy, you cannot deploy new extension properties that might be required for your application. For example, if you require a user name to start or stop and probe your application, you will typically have to hard code that user name within your scripts. Instead, you could subclass the GDSv2 resource type and then create a new extension property within the subclassed resource type.

Note - If you subclass a GDSv2 resource type and add a new extension property to the RTR file and provide a default value for that property, be careful how you provide those default values. The following table provides some sample default values that might fit what you want to achieve:

DEFAULT ="";	Blank string entry
DEFAULT = "foo";	String entry
DEFAULT ="foo bar";	String entry with multiple entries
DEFAULT ="'foo bar \\\*'";	String entry with multiple entries and special characters. Single quotes are enclosed by double quotes.
DEFAULT =2;	Integer value 2
DEFAULT =TRUE;	Boolean entry
DEFAULT ="NONE";	Enum entry

How to Subclass the `ORCL.gds` Resource Type

On one cluster node, assume the root role.
Copy the ORCL.gds Resource Type Registration file.
```
# cd /opt/ORCLscgds/etc
# cp ORCL.gds your path/my.gds
```
Note - For consistency, copy the RTR file on all nodes of the cluster.
Edit the copied file your path/my.gds.
Change the following entries to reflect your new resource type name:
```
RESOURCE_TYPE = “gds”;
VENDOR_ID = my;
#% SERVICE_NAME = “my.gds”;
```
Create a new extension property within the new Resource Type Registration file. For example, edit your path/my.gds and copy the Boot_command extension property and amend it the Username extension property.
```
{ PROPERTY = Username; EXTENSION; STRING; DEFAULT = ""; TUNABLE = AT_CREATION; 
           DESCRIPTION = "Username for my application";
}
```
Note - For consistency, edit the RTR file on all nodes of the cluster.

Other extension properties can be created and copied from an existing extension property to meet your requirements. For example, the Boot_command extension property was copied to create the Username extension property above. However, the TUNABLE attribute was amended to use AT_CREATION. See the property_attributes(5) man page for more information about resource property attributes.
Register and list the new Resource Type.
```
# clresourcetype register -f your path/my.gds my.gds
```

Create a resource of the new Resource Type.

# clresourcegroup create newrg
# clresource create -g newrg -t my.gds \
-p Start_command=your start command \
-p Username=me -d newrs

List the new extension property from your resource.
```
# clresource show -p username newrs
```
You have now successfully subclassed the ORCL.gds resource type. Your new resource type [my.gds] will behave exactly as the ORCL.gds resource type, except that you have introduced a new extension property.

Note - To retrieve the contents of the Username extension property, use the /usr/cluster/bin/scha_resource_get program as shown in the demo scripts below.
```
root@node1:~# user=$(/usr/cluster/bin/scha_resource_get -O extension -R newrs -G newrg username |
     tail  -1)
root@node1:~# echo $user
me
root@node1:~#
```

How to Subclass the `ORCL.gds_proxy` Resource Type

The steps to subclass the ORCL.gds_proxy resource type are similar to the steps for subclassing the ORCL.gds resource type.

On one cluster node, assume the root role.
Copy the ORCL.gds_proxy Resource Type Registration file.
```
# cd /opt/ORCLscgds/etc
# cp ORCL.gds_proxy your path/my.gds_proxy
```
Note - For consistency, copy the RTR file on all nodes of the cluster.
Edit the copied file your path/my.gds_proxy.
Change the following entries to reflect your new resource type name:
```
RESOURCE_TYPE = “gds_proxy”;
VENDOR_ID = my;
#% SERVICE_NAME = “my.gds_proxy”;
```
Create a new extension property within the new Resource Type Registration file. For example, edit your path/my.gds_proxy and copy the Boot_command extension property and amend it as the Username extension property.
```
{ PROPERTY = Username; EXTENSION; STRING; DEFAULT = ""; TUNABLE = AT_CREATION; 
	        DESCRIPTION = "Username for my application";
}
```
Note - For consistency, edit the RTR file on all nodes of the cluster.

Other extension properties can be created and copied from an existing extension property to meet your requirements. For example, the Boot_command extension property was copied to create the Username extension property. However, the TUNABLE attribute was amended to use AT_CREATION. See the property_attributes(5) man page for more information about resource property attributes.
Register and list the new Resource Type.
```
# clresourcetype register -f your path/my.gds_proxy my.gds_proxy
```

Create a resource of the new Resource Type.

# clresourcegroup create -S newsrg
# clresource create -g newsrg -t my.gds_proxy \
-p Prenet_start_command=your prenet_start command \
-p Username=me -d newsrs

List the new extension property from your resource.
```
# clresource show -p username newsrs
```
You have now successfully subclassed the ORCL.gds_proxy resource type. Your new resource type [my.gds_proxy] will behave exactly as the ORCL.gds_proxy resource type, except that you have introduced a new extension property.

Note - To retrieve the contents of the Username extension property, use the /usr/cluster/bin/scha_resource_get program as shown in the demo scripts below.
```
root@node1:~# user=$(/usr/cluster/bin/scha_resource_get -O extension -R newsrs -G newsrg username |
            tail  -1)
root@node1:~# echo $user
me
root@node1:~#
```

Oracle® Solaris Cluster Generic Data Service (GDS) Guide