Distribution EOLE

Pour la procédure d'Upgrade 2.4/2.4.1:

La procédure qui s'appliquait auparavant pour les upgrades 2.0-2.1 / 2.1-2.2 devrait être valide ici aussi moyennant quelques adaptations (gestion des dicos locaux, à priori déjà pris en compte dans les développements précédents).

La procédure d'origine est :

1. upgrade de Zéphir. A ce moment les variantes présentes sur la version précédente étaient recréées automatiquement pour la nouvelle version, et déclarées comme équivalentes pour la migration (les équivalences sont modifiables depuis l'appli Zéphir si besoin)
2. upgrade des serveurs clients. En fin de procédure upgrade-Auto :
• la fonction serveurs.migrate_serveur(<id_serveur>, infos_matérielles, nouveau_module) est appelée. Cela provoque une bascule du serveur sur le nouveau module dans Zéphir, en prenant automatiquement la variante déclarée comme équivalente (nécessite la saisie d'un login/mdp Zéphir).
• Zéphir effectue une remontée des données locales sur Zéphir, puis une descente de configuration depuis Zéphir (pour récupérer d'éventuelles données de la variante).

rqe: à la différence de la migration (2.2/2.3 -> 2.4 ou 2.4.1), la configuration n'a pas besoin d'être préparée sur Zéphir.
Elle est éventuellement mise à jour par la procédure d'upgrade sur le module, puis remontée sur Zéphir.

les changements suivants sont introduits pour l'upgrade vers 2.4.1 (et suivants).

• Zéphir n'étant pas forcément disponible sur la dernière version d'Eole, l'étape de création automatique des variantes à l'upgrade de Zéphir n'est pas possible. Pour pallier au problème, un bouton import des données 2.4 (version n-1) à été ajouté au niveau de la distribution 2.4.1 (page modules). Le fonctionnement de cette fonction est le suivant:
  • copie des dictionnaires locaux déclarés dans eole 2.4 sur eole 2.4.1
  • copie des variantes existantes dans eole 2.4 sur eole 2.4.1 et déclaration automatique des équivalences de variantes.

rqe: cette fonction peut etre lancée, plusieurs fois, mais seuls les données non existantes en 2.4.1 sont pris en compte.
Cela peut permettre de prendre en compte des variantes ajoutées en 2.4 après une première copie, sans perdre d'éventuelles corrections effectuées sur les données 2.4.1 entre temps.
Pour reporter des modifications dans une variante déjà recopiée, il faudra mettre à jour les données 'à la main' ou utiliser la fonction *importer/copier* de la page des variantes selon le cas.

• sur les modules enregistrés, le fonctionnement devrait être le même que dans l'upgrade 'classique'.

reste à :

• valider le comportement en fin d'Upgrade-Auto (reconfigure/instance/...)
• documenter les fonctions de copie de variante et la procédure d'upgrade dans la doc Zéphir
• tester :)

En début de procédure, les éventuels dictionnaires locaux de la version antérieure sont mis de côté (qu'on soit enregistré sur Zéphir ou non) pour limiter les risques d'errreurs liées à creoled.

Les messages de fin de procédure ont été adaptés au cas d'Upgrade-Auto

Appliqué par commit zephir-client:6fbf0aea62900a9e3b5f4bfa46d87a49e6bb5c47.