Modification du code de méthode

Si seul le code de méthode a été modifié dans le type de ressources mis à jour, il est crucial de déterminer si le nouveau code de méthode est compatible avec la version antérieure. Ceci vous permet de savoir si vous devez enregistrer ce nouveau code sous un nouveau nom de chemin d'accès ou si vous pouvez écraser les méthodes antérieures.

Si vous pouvez appliquer les nouvelles méthodes d'Arrêt, Arrêt_après_réseau et Fini (à condition d'être déclarées) aux ressources initialisées ou exécutées par les versions antérieures des méthodes de Démarrage , Arrêt_avant_réseau ou Init, vous pouvez écraser les anciennes méthodes par les nouvelles.

Si le nouveau code de méthode n'est pas compatible avec la version antérieure, vous devez arrêter une ressource ou la supprimer de la configuration à l'aide des versions antérieures avant de pouvoir la migrer vers le type de ressources mis à niveau. Si les nouvelles méthodes écrasent les anciennes, il peut s'avérer nécessaire d'arrêter (voire de basculer en mode non géré) toutes les ressources de ce type avant de mettre ce dernier à niveau. Si les nouvelles et les anciennes méthodes sont enregistrées séparément (tout en étant accessibles simultanément), vous pouvez, même en l'absence de rétrocompatibilité, installer la nouvelle version du type de ressources et mettre les ressources à niveau individuellement.

Même si les nouvelles méthodes sont rétrocompatibles, il peut s'avérer nécessaire de mettre à niveau une ressource pour utiliser les nouvelles méthodes tandis que les autres ressources continuent d'utiliser les méthodes antérieures. Vous devez encore enregistrer les nouvelles méthodes dans un répertoire distinct plutôt que d'écraser les méthodes antérieures.

L'enregistrement des méthodes de chaque version du type de ressources dans un répertoire distinct permet de rebasculer les ressources vers la version antérieure en cas de problème avec la nouvelle version.

Une autre approche consiste à inclure toutes les versions précédentes encore prises en charge dans le package. Le cas échéant, le nouveau package remplace la version antérieure sans écraser ni supprimer les chemins d'accès aux méthodes antérieures. C'est au développeur du type de ressources de décider du nombre de versions antérieures prises en charge.

nous vous recommandons d'écraser les méthodes ou les méthodes pkgrm/ pkgadd sur un noeud appartenant au cluster. Si le gestionnaire RGM doit exécuter une méthode qui n'est pas accessible sur le disque, ceci risque d'engendrer des résultats inattendus. La suppression ou le remplacement du code binaire d'une méthode en cours d'exécution peut également engendrer des résultats inattendus.