There are two requirements related to the installation of the new 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 of the declared method pathnames and the monitor program for the new type must be on disk and executable. The old method and monitor programs must remain in place as long as the resource is in use.
To decide on the most appropriate packaging, the resource type implementor must consider the following:
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 method code change?
Does the monitor code change?
Are the new methods or monitor code compatible with the previous version?
Some resource type upgrades do not involve new method or monitor code. For example, a resource type upgrade might only change the default value or tunability of a resource property. Since the method code is not changing, the only requirement for installing the upgrade is to have a valid pathname to a readable RTR file.
If there is no need to reregister the old resource type, the new RTR file can overwrite the previous version. Otherwise the new RTR file can be placed in a new pathname.
If the upgrade changes the default value or tunability of a property, the Validate method for the new version can verify at migration time that the existing property attributes are valid for the new resource type. If the upgrade changes the min, max, or type attributes of a property, the scrgadm command automatically validates these constraints at migration time.
The upgrade documentation must call out any new default property attributes. The documentation must inform the system administrator that existing resource properties are editable to appropriate values using the same command that edits the Type_version property to upgrade the resource to the new resource type version.
If the upgrade adds or deletes properties, it is likely that some callback methods or monitor code also must be changed.
If the monitor code is the only change in the updated resource type, then the package installation can overwrite the monitor binaries. The documentation must instruct the system administrator to suspend monitoring before installing the new package.
If the method code is the only change in the updated resource type, it is important to determine whether the new method code is compatible with the previous version. This determines whether the new method code must be stored in a new pathname or whether the old methods can be overwritten.
If the new Stop, Postnet_stop and Fini methods (if declared) can be applied to resources that were initialized or started by the old versions of the Start, Prenet_stop, or Init methods, then it is possible to overwrite the old methods with the new methods.
If the new method code is not compatible with the previous version, then it is necessary to stop or unconfigure a resource using the old versions of the methods before it can be migrated to the upgraded resource type. If the new methods overwrite the old ones, it can require shutting down (and possibly unmanaging) all resources of the type before doing the resource type upgrade. If the new methods are stored separately from the old (and both are accessible at once), then even without backward compatibility it is possible to install the new resource type version and upgrade the resources one by one.
Even if the new methods are backward compatible, it might be a requirement to upgrade one resource at a time to use the new methods, while other resources continue to use the old methods. It still is necessary to store the new methods in a separate directory rather than overwriting the old ones.
An advantage to storing each resource type version's methods in a separate directory is that it makes it easy to switch resources back to the older resource type version if a problem arises with the newer version.
One packaging approach is to include all of the earlier versions that are still supported in the package. This permits the new package version to replace the older version, without overwriting or deleting the old method paths. It is up to the resource type developer to decide how many previous versions to support.
It is not recommended to overwrite methods or pkgrm/pkgadd methods on a node that is currently in the cluster. If the RGM were to call a method when the method is not accessible on disk, unexpected results can occur. Removing or replacing the binary of a running method might also cause unexpected results.