Capítulo 3 Actualización de un tipo de recurso

Este capítulo trata las cuestiones que se deben comprender para actualizar un tipo de recurso y migrar un recurso.

• Información general

• Archivo de registro del tipo de recurso

• Propiedad Type_version del recurso

• Migración de un recurso a una versión diferente

• Modernización de un tipo de recurso y adaptación a una versión anterior

• Valores predeterminados de la propiedad

• Documentación del desarrollador del tipo de recurso

• Implementaciones del nombre y del supervisor del tipo de recurso

• Modernizaciones de las aplicaciones

• Ejemplos de la modernización del tipo de recurso

• Requisitos de instalación para los paquetes de tipos de recursos

Información general

Los administradores de sistemas tienen que poder instalar y registrar una nueva versión de un tipo de recurso existente para permitir el registro de múltiples versiones de un tipo de recurso determinado y para migrar un recurso a una nueva versión del tipo de recurso, sin tener que eliminar y volver a crear el recurso. Los desarrolladores de recursos tienen que comprender los requisitos para proporcionar una actualización del tipo de recurso y una migración del recurso.

Los tipos de recurso desarrollados de manera que admitan una modernización se denominan habilitados para modernización.

Una nueva versión de un tipo de recurso puede diferir de una versión anterior en muchas formas:

• Los atributos de las propiedades del tipo de recurso pueden cambiar

• El conjunto declarado de propiedades de recursos, incluidas propiedades estándar y de extensión, puede cambiar

• Los atributos de las propiedades de recursos, como default, min, max, arraymin, arraymax o la capacidad de ajuste pueden cambiar

• El conjunto de métodos declarados puede variar

• La implementación de métodos o supervisores puede cambiar.

El desarrollador del tipo de recursos decide cuándo se puede migrar un recurso a una nueva versión, entre las siguientes opciones de ajuste. Las opciones aparecen ordenadas de la menos a la más restrictiva:

• En cualquier momento (ANYTIME)

• Cuando el recurso no esté supervisado (WHEN_UNMONITORED )

• Cuando el recurso esté fuera de línea (WHEN_OFFLINE)

• Cuando el recurso esté inhabilitado (WHEN_DISABLED)

• Cuando el grupo de recursos no esté siendo gestionado (WHEN_UNMANAGED)

• En el momento de la creación (AT_CREATION)

En este capítulo se usa la orden scrgadm cuando se trata de las modernizaciones. Sin embargo, el administrador no está obligado a usar el comando scrgadm, sino que también puede utilizar la GUI o el comando scsetup para realizar la modernización.

Archivo de registro del tipo de recurso

Nombre del tipo de recurso

Los tres componentes del nombre del tipo de recurso son propiedades especificadas en el archivo RTR, como ID_proveedor, tipo_recurso y versión_TR. La orden scrgadm introduce los delimitadores de punto y de punto y coma para crear el nombre del tipo de recurso:

ID_proveedor.tipo_recurso:versión_tr

El prefijo ID_proveedor sirve para diferenciar dos archivos de registro con el mismo nombre, suministrados por proveedores diferentes. El sufijo versión_TR establece una distinción entre las diferentes versiones registradas (modernizaciones) del mismo tipo de recurso básico. Para garantizar que el ID_proveedor sea único, se recomienda utilizar el símbolo bursátil de la empresa que crea el tipo de recurso.

El registro del tipo de recurso falla si la cadena RT_version incluye un espacio en blanco, una tabulación, una barra oblicua ( /), una barra inversa (\), un asterisco (*), una interrogación (?), una coma (,), un punto y coma (;), un corchete de apertura ([) o un corchete de cierre (]).

La propiedad RT_Version, que era opcional en Sun Cluster 3.0, es obligatoria desde Sun Cluster 3.1.

El nombre completo es el nombre que devuelve la orden siguiente:

scha_resource_get -O Type -R nombre_recurso -G nombre_grupo_recurso

Los nombres del tipo de recursos registrados antes de Sun Cluster 3.1 siguen usando el formato:

ID_proveedor.tipo_recurso

Directivas

Los archivos RTR de los tipos de recursos habilitados para la modernización deben incluir una directiva #$upgrade, seguida de cero o más directivas con el formato:

#$upgrade_from versión capacidad_ajuste

La directiva upgrade_from consiste en la secuencia #$upgrade_from, seguida de RT_Version, seguida a su vez de la limitación de la capacidad de ajuste en el recurso. Si el tipo de recurso desde el que se está realizando la modernización no tiene una versión, RT_Version se especifica como la secuencia vacía, como muestra el último de los siguientes ejemplos:

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

RGM impone estas limitaciones a un recurso cuando el administrador intenta cambiar el valor Type_version del recurso. Si la versión actual del tipo de recurso no aparece en la lista, RGM impone la capacidad de ajuste de WHEN_UNMANAGED.

Estas directivas deben aparecer entre la sección de declaraciones de la propiedad del tipo de recurso del archivo RTR y la sección de declaraciones del recurso del archivo RTR. Consulte rt_reg(4).

Cambio de RT_Version en un archivo RTR

Cambie la secuencia RT_Version de un archivo RTR siempre que cambie el contenido de éste. El valor de esta propiedad debe dejar claro cuál es la versión más reciente del tipo de recurso y cuál es la más antigua. No es necesario cambiar la secuencia RT_Version si no hay cambios en el archivo RTR.

Nombres de los tipos de recursos en versiones anteriores de Sun Cluster

Los nombres de los tipos de recursos de Sun Cluster 3.0 no contenían el sufijo de la versión:

vendor_id.resource_name

Un tipo de recurso registrado originalmente en Sun Cluster 3.0 sigue teniendo un nombre con este formato aunque se modernice el software del clúster a Sun Cluster 3.1 o versiones posteriores. Del mismo modo, un tipo de recurso cuyo archivo RTR carezca de la directiva #$upgrade recibe un nombre con formato de Sun Cluster 3.0, sin el sufijo de versión, si el archivo RTR está registrado en un clúster que funcione con el software Sun Cluster 3.1 o posterior.

Puede registrar archivos RTR con las directivas #$upgrade o #$upgrade_from de Sun Cluster 3.0, pero la migración de recursos a nuevos tipos de recursos de Sun Cluster 3.0 no se admitirá.

Propiedad Type_version del recurso

La propiedad del recurso estándar Type_version almacena la propiedad RT_Version de un tipo de recurso. Esta propiedad no aparece en el archivo RTR. El administrador del sistema edita este valor de propiedad con el siguiente comando:

scrgadm -c -j recurso -y Type_version=versión_nueva

La capacidad de ajuste de esta propiedad se deriva de:

• La versión actual del tipo de recurso

• Las directivas #$upgrade_from del archivo RTR

Utilice los siguientes valores de ajuste en las directivas #$upgrade_from:

ANYTIME

Si no hay restricciones sobre el momento de modernización del recurso. El recurso puede estar totalmente en línea.

WHEN_UNMONITORED

Si se sabe que los métodos Update, Stop, Monitor_check y Postnet_stop de la nueva versión del tipo de recurso son compatibles con métodos de inicio de versiones anteriores del tipo de recurso, (Prenet_stop y Start), y que el método Fini de la nueva versión del tipo de recurso es compatible con el método Init de las versiones anteriores. En esta situación sólo será necesario cerrar el programa de supervisión del recurso antes de la modernización

WHEN_OFFLINE

Si los metodos versión del tipo de recursoUpdate, Stop, Monitor_check o Postnet_stop no son compatibles con los métodos de inicio de las versiones de los tipos de recursos más antiguos (Prenet_stop y Start) pero sí son compatibles con el método Init de las versiones más antiguas, el recurso debe estar fuera de línea cuando se aplique la modernización.

WHEN_DISABLED

Similar a WHEN_OFFLINE. Sin embargo, este valor de capacidad de ajuste impone la condición más firme de que se inhabilite el recurso.

WHEN_UNMANAGED

Si el método Fini de la nueva versión del tipo de recurso no es compatible con el método Init de versiones anteriores. Este valor de capacidad de ajuste requiere que el grupo de recursos se ponga en estado no gestionado antes de modernizar el recurso.

AT_CREATION

Si los recursos no se pueden actualizar a la nueva versión del tipo de recurso. Sólo se pueden crear recursos nuevos de la nueva versión.

La capacidad de ajuste AT_CREATION significa que el desarrollador del tipo de recurso puede impedir la migración de un recurso al tipo nuevo. En este caso, el administrador del sistema debe borrar y volver a crear el recurso. Equivale a declarar que la versión del recurso sólo se puede fijar en el momento de la creación.

Migración de un recurso a una versión diferente

Un recurso absorbe la nueva versión del tipo de recurso cuando el administrador del sistema edita la propiedad Type_version del recurso. Este proceso sigue las mismas convenciones empleadas para editar otras propiedades del recurso, salvo que cierta información se derivara u obtuviera de la nueva versión del tipo de recurso, y no de la versión actual:

• Los atributos de la propiedad del recurso de todas las propiedades, como min, max, arraymin, arraymax, valor predeterminado y capacidad de ajuste, se obtienen de la nueva versión del tipo de recurso

• La capacidad de ajuste aplicable a la propiedad Type_version se obtiene de las directivas #$upgrade_from del archivo RTR y la propiedad RT_version del tipo de recurso del recurso existente. Esta capacidad de ajuste es diferente de la descrita en property_attributes(5).

• Se aplicará el método Validate de la nueva versión del tipo de recurso lo que garantiza que los atributos de propiedad sean válidos para el nuevo tipo de recurso. Si los atributos existentes de la propiedad del recurso no cumplen las condiciones de validación de la nueva versión del tipo de recurso, el administrador del sistema debe proporcionar valores válidos para dichas propiedades en la línea de órdenes scrgadm. Esto puede ocurrir si la versión más reciente del tipo de recurso comienza a usar una propiedad que no se declaró en la versión anterior y que no tiene una opción predeterminada. También puede ocurrir si el recurso ya tiene una propiedad a la que se le ha asignado un valor no válido para la nueva versión del tipo de recurso.

• Las propiedades del recurso declaradas en una versión anterior del tipo de recurso se pueden no declarar en la versión más actual. Cuando se migra el recurso a una versión más moderna, la propiedad se elimina de éste.

El método Validate puede consultar el Type_version actual del recurso (con scha_resource_get) y el nuevo Type_version (que se pasa a la línea de comandos Validate). Por tanto, Validate puede descartar las modernizaciones a partir de versiones no admitidas.

Modernización de un tipo de recurso y adaptación a una versión anterior

El apartado “Upgrading a Resource Type” de Sun Cluster Data Services Planning and Administration Guide for Solaris OS contiene información adicional sobre la modernización o migración de un tipo de recurso.

Cómo se moderniza un tipo de recurso

1. Lea la documentación sobre la modernización de un nuevo tipo de recurso para ver los cambios de los tipos de recurso y las limitaciones a los ajustes del recurso.

2. Instale el paquete de modernización del tipo de recurso en todos los nodos de clúster.

   La práctica recomendada para instalar paquetes de nuevos tipos de recursos es la misma que para el despliegue de modernizaciones: pkgadd se produce cuando el nodo se arranca en modo sin clúster.

   Hay situaciones en las que sería posible instalar paquetes de nuevos tipos de recursos en un nodo en modo clúster:

   • Si la instalación del paquete del tipo de recurso no cambia el código del método y sólo actualiza el supervisor, será necesario detener la supervisión de todos los recursos de ese tipo durante la instalación.

   • Si la instalación del paquete del tipo de recurso no cambia el código del supervisor ni el método, no será necesario detener la supervisión del recurso durante la instalación, porque ésta sólo está poniendo un nuevo archivo RTR en el disco.

3. Registre la nueva versión del tipo de recurso con la orden scrgadm (o equivalente), que debe hacer referencia al archivo RTR de la modernización.

   RGM crea un nuevo tipo de recurso, cuyo nombre tiene el formato

   ID_proveedor.tipo_recurso:versión

4. Si la modernización del tipo de recurso se instala sólo en un subgrupo de nodos, debe fijar la propiedad Installed_nodes del nuevo tipo de recurso en los nodos en los que se instala efectivamente.

   Cuando un recurso incorpora el nuevo tipo (porque se cree de cero o se actualice), RGM requiere que el grupo de recursos nodelist sea un subconjunto de la lista de Installed_nodes del tipo de recurso.

   scrgadm -c -t tipo_recurso -h lista_nodos_instalados

5. Para cada recurso del tipo premodernizado que se vaya a migrar al tipo modernizado, invoque scswitch para cambiar el estado del recurso o su grupo de recursos al estado adecuado, como indica la documentación de modernización.

6. Para cada recurso del grupo premodernizado que se vaya a migrar al tipo modernizado, edite el recurso, cambiando su propiedad Type_version a la nueva versión.

   scrgadm -c -j recurso -y Type_version=versión_nueva

   Si fuera necesario, cambie otras propiedades del mismo recurso a los valores apropiados de la misma orden.

7. Restaure el estado anterior del recurso o grupo de recursos, invirtiendo el comando que se invoca en el Paso 5.

Cómo adaptar un recurso a una versión anterior de su tipo de recurso

Es posible adaptar un recurso a una versión anterior de su tipo de recurso. Las condiciones en las que esto es posible son más restrictivas que aquéllas en las que es posible modernizar el tipo de recurso a una nueva versión. Primero debe dejar el grupo de recursos sin gestionar. Además, sólo será posible recuperar versiones modernizables del tipo de recurso. Las versiones modernizables se pueden identificar con la orden scrgadm -p. En la salida, las versiones habilitadas para la modernización, contienen el sufijo :version.

1. Vaya al grupo de recursos que contenga el recurso que desee adaptar una versión anterior.

   scswitch -F -g grupo_recurso

2. Inhabilite el recurso y todos los recursos del grupo.

   scswitch -n -j recurso_que_adaptar scswitch -n -j recurso1 scswitch -n -j recurso2 scswitch -n -j recurso3 ...

   ---

   Nota –

   Inhabilite los recursos en orden de dependencia, empezando con el más dependiente (recursos de aplicación) hasta llegar al menos dependiente (recursos de dirección de red).

   ---

3. Deje el grupo de recursos sin gestión.

   scswitch -u -g grupo_recurso

4. ¿La versión anterior del tipo de recurso que desea adaptar sigue registrada en el clúster?

   • Si es así, vaya al paso siguiente.

   • En caso contrario, vuelva a registrar la versión anterior que desee.

     scrgadm -a -t nombre_tipo_recurso

5. Adapte el recurso; especifique cuál es la versión anterior que desea para Type_version.

   scrgadm -c -j recurso_que_adaptar -y Type_version=versión_anterior

   Si fuera necesario, cambie otras propiedades del mismo recurso a los valores apropiados de la misma orden.

6. Ponga el grupo de recursos que contiene el recurso que ha adaptado en un estado gestionado, habilite todos los recursos y ponga el grupo en línea.

   scswitch -Z -g grupo_recurso

Valores predeterminados de la propiedad

RGM almacena todos los recursos, de forma que cualquier propiedad que el administrador del sistema no haya fijado explícitamente (y que había sido predeterminada) no quede almacenada en la entrada de recurso del CCR (almacén de configuración de clúster). RGM obtiene el valor predeterminado de una propiedad de recurso ausente del tipo de recurso (o, si no se definiera aquí, de un valor predeterminado definido por el sistema) cuando se lee un recurso desde el CCR. Este método de almacenamiento de las propiedades permite que un tipo de recurso modernizado defina nuevas propiedades o nuevos valores predeterminados para propiedades existentes.

Cuando se editan las propiedades de recurso, RGM almacena en el CCR las especificadas en el comando de edición.

Si una versión modernizada del tipo de recurso declara un nuevo valor valores predeterminados para una propiedad predeterminadapredeterminado para una propiedad predeterminada, el nuevo valor predeterminado es heredado por los recursos existentes, aunque la propiedad sólo se declare ajustable en AT_CREATION o en WHEN_DISABLED. Si la aplicación del nuevo valor predeterminado hace que falle un método como Stop, Postnet_stop o Fini, el implantador del tipo debe restringir el estado del recurso en el momento de su modernización, según corresponda. Esto se hace limitando la capacidad de ajuste de la propiedad Type_version.

El método Validate de la nueva versión del tipo de recurso puede comprobar si los atributos existentes de la propiedad son los adecuados. Si no lo son, el administrador del sistema puede editar las propiedades de un recurso para indicar los valores correctos en la misma orden que edita la propiedad Type_version para modernizar el recurso a la nueva versión del tipo de recurso.

Los recursos que se crearon en Sun Cluster 3.0 no heredan los nuevos atributos predeterminados de la propiedad del tipo de recurso cuando se migran a una versión posterior, porque sus propiedades predeterminadas se guardan en el CCR.

Documentación del desarrollador del tipo de recurso

El desarrollador del tipo de recurso debe proporcionar la documentación con el nuevo recurso en la que:

• Describa cualquier adición, cambio o eliminación en la propiedad

• Describa cómo hacer que las propiedades cumplan los nuevos requisitos

• Establezca las limitaciones de las capacidades de ajustes de los recursos

• Indique cualquier atributo predeterminado nuevo de la propiedad

• Informe al administrador del sistema de que es posible editar las propiedades de los recursos para que se ajusten a los valores apropiados con el mismo comando empleado para editar la propiedad Type_version para modernizar el recurso a la nueva versión del tipo de recurso

Implementaciones del nombre y del supervisor del tipo de recurso

Puede registrar un tipo de recurso habilitado para modernización en Sun Cluster 3.0, pero su nombre se registra en el CCR sin el sufijo de la versión. Para que se ejecute correctamente en Sun Cluster 3.0 y Sun Cluster 3.1, el supervisor de este tipo de recurso debe ser capaz de manejar las dos convenciones de asignación de nombre:

ID_proveedor.nombre_recurso:versión
ID_proveedor.nombre_recurso

El código del supervisor puede determinar el nombre adecuado que se debe utilizar, ejecutando el equivalente de:

scha_resourcetype_get -O RT_VERSION -T VEND.myrt
scha_resourcetype_get -O RT_VERSION -T VEND.myrt:vers

Después, compare los valores de salida con vers. Sólo uno de estos comandos servirá para un valor concreto de vers, porque no es posible registrar la misma versión del tipo de recurso dos veces, con dos nombres diferentes.

Modernizaciones de las aplicaciones

La modernización del código de aplicación es diferente de la modernización del código del agente, aunque algunas de las cuestiones que surgen son similares. Una modernización de una aplicación puede estar o no acompañada de una modernización del tipo de recurso.

Ejemplos de la modernización del tipo de recurso

Estos ejemplos muestran diferentes situaciones de modernización e instalación de los tipos de recursos. La información de los paquetes y la capacidad de ajuste se han seleccionado en función de los tipos de cambios que se hayan realizado en la implementación del tipo de recurso. La capacidad de ajuste se aplica a la migración del recurso al nuevo tipo.

Todos los ejemplos presuponen que:

• El tipo de recurso se incluye en un paquete de Solaris. Consulte pkgadd(1M) y pkgrm(1M)

• Sólo hay una versión anterior del tipo de recurso y, por tanto, sólo hay una directiva #$upgrade_from en el nuevo archivo RTR

• El procedimiento de instalación no eliminará ni sobrescribirá los métodos si es posible que RGM invoque los métodos mientras se eliminan del disco

• Los nuevos métodos son compatibles con los antiguos, salvo que se indique lo contrario

• Los recursos y grupos de recursos se ponen en el estado necesario antes de la instalación o migración, con la orden correcta scswitch(1M) o equivalente. El ejemplo siguiente muestra cómo poner el grupo de recursos en un estado no gestionado:

  scswitch -M -n -j recurso scswitch -n -j recurso scswitch -F -g grupo_recursos scswitch -u -g grupo_recursos

• Los tipos de recursos se registran con la orden siguiente:

  scrgadm -a -t tipo_recurso -f ruta_a_archivo_RTR

• Los tipos de recursos se migran con la orden siguiente:

  scrgadm -c -j recurso -y Type_version=versión \ -y propiedad=valor \ -x propiedad=valor ...

• Los recursos y grupos de recursos se devuelven a su estado anterior tras la migración, con el comando scswitch(1M) adecuado, o equivalente:

  scswitch -M -e -j recurso scswitch -e -j recurso scswitch -o -g grupo_recurso scswitch -Z -g grupo_recurso

Es posible que el desarrollador de tipos de recursos tenga que especificar valores más restrictivos para la capacidad de ajuste que los que se indican en estos ejemplos. Los valores de la capacidad de ajuste dependen de los cambios precisos que se realicen en la implementación del tipo de recurso. Asimismo, el desarrollador del tipo de recurso puede decidir utilizar un esquema de paquetes diferente, en lugar del de Solaris que se emplea en estos ejemplos.

Requisitos de instalación para los paquetes de tipos de recursos

Hay dos requisitos relacionados con la instalación de los nuevos paquetes de tipos de recursos:

• Cuando se registra un nuevo tipo de recurso, su archivo RTR debe estar accesible en disco

• Cuando se crea un recurso del nuevo tipo, todos los nombres de rutas de los métodos declarados y el programa supervisor del nuevo tipo deben estar en disco y deben ser ejecutables. El método y los programas supervisores antiguos deben permanecer en su lugar mientras el recurso se esté utilizando.

  Para decidir cuál es el paquete más adecuado, el implantador del tipo de recurso debe tener presente:

  • ¿Cambia el archivo RTR?

  • ¿Cambian el valor predeterminado o la capacidad de ajuste de una propiedad?

  • ¿Cambian los valores min o max de una propiedad?

  • ¿Agrega o elimina propiedades esta modernización?

  • ¿Cambia el código del método?

  • ¿Cambia el código del supervisor?

  • ¿Son compatibles los nuevos métodos o el código del supervisor con la versión anterior?

Información que se tiene que conocer antes de cambiar el archivo RTR

Algunas modernizaciones del tipo de recurso no implican la utilización de nuevos métodos o código del supervisor. Por ejemplo, una modernización de tipo de recurso puede cambiar sólo el valor predeterminado o la capacidad de ajuste de una propiedad del recurso. Dado que no cambia el código de método, el único requisito para instalar la modernización es disponer de un nombre de ruta válido a un archivo RTR legible.

Si no es necesario volver a registrar el antiguo tipo de recurso, el nuevo archivo RTR puede sobrescribir la versión anterior. En caso contrario, se puede situar el archivo RTR en un nuevo nombre de ruta.

Si la modernización cambia el valor predeterminado o la capacidad de ajuste de una propiedad, el método Validate de la nueva versión puede verificar en el momento de la migración que los atributos de la propiedad sean válidos para el nuevo tipo de recurso. Si la modernización cambia los atributos min, max o type de una propiedad, la orden scrgadm valida automáticamente estas limitaciones en el momento de la migración.

La documentación de modernización debe indicar cualquier atributo nuevo predeterminado de las propiedades. La documentación debe informar al administrador del sistema de que las propiedades de recurso se pueden modificar según los valores adecuados con el mismo comando que edita la propiedad Type_version para modernizar el recurso a la nueva versión del tipo de recurso.

Si la modernización agrega o elimina propiedades, es probable que haya que modificar también algunos métodos de rellamada o código del supervisor.

Cambio del código del supervisor

Si el código del supervisor es el único cambio del tipo de recurso actualizado, la instalación del paquete podrá sobrescribir los binarios del supervisor. La documentación debe indicarle al administrador del sistema que suspenda la supervisión antes de instalar el paquete nuevo.

Cambio del código del método

Si el código del método es el único cambio del tipo de recurso actualizado, es importante determinar si el nuevo código del método es compatible con la versión anterior. Esto determina si el nuevo código del método se debe almacenar en un nuevo nombre de ruta o si se pueden sobrescribir los métodos antiguos.

Si los nuevos métodos Stop, Postnet_stop y Fini (si se declaran) se pueden aplicar a los recursos que se inicializaron o iniciaron por las versiones anteriores de los métodos Start, Prenet_stop o Init será posible sobrescribir los métodos antiguos con los nuevos.

Si el nuevo código del método no es compatible con la versión anterior, será necesario detener o desconfigurar un recurso con las versiones anteriores de los métodos antes de poder migrarlo al tipo de recurso modernizado. Si los nuevos métodos sobrescriben los antiguos, es posible que sea necesario apagar (y probablemente dejar sin gestión) todos los recursos del tipo antes de realizar la modernización del tipo de recurso. Si los nuevos métodos se guardan aparte de los antiguos (y ambos resultan accesibles inmediatamente), aún sin la compatibilidad con versiones anteriores será posible instalar la nueva versión del tipo de recurso y modernizar los recursos uno a uno.

Aunque los métodos nuevos sean compatibles con versiones anteriores, es posible que haya que modernizar los recursos de uno en uno para utilizar los nuevos métodos, mientras otros recursos siguen usando los métodos antiguos. Sigue siendo necesario guardar los métodos nuevos en un directorio aparte, en lugar de sobrescribir los antiguos.

Ello facilita el regreso a la versión anterior del tipo de recurso si surgiera un problema con la versión nueva.

Una forma de empaquetado consiste en incluir todas las versiones anteriores que siguen estando admitidas en el nuevo paquete. Esto permite que la nueva versión del paquete sustituya la versión anterior, sin sobrescribir ni suprimir las rutas antiguas a los métodos. El desarrollador del tipo de recurso deberá decidir cuántas versiones anteriores deben estar admitidas.

No se recomienda sobrescribir métodos pkgrm/pkgadd en un nodo que esté actualmente en el clúster, ya que si RGM llama a un método cuando éste no está accesible en disco, se pueden producir resultados inesperados. La eliminación o sustitución del binario de un método en ejecución puede provocar también resultados inesperados.