Problème bloquant lors d'un upgrade depuis une 6.2.22 vers une 6.3.5

Request description

Je tente d’upgrade une base installée en 6.2.22 vers une 6.3.5.

Mon pipeline déroule l’upgrade sur mes 3 environnements dev puis int puis ope.

L’environnement de dev avait déjà été upgrade depuis une 6.2.22 vers la 6.3.3 début février mais je n’ai pas déroulé la suite du pipeline à ce moment là. L’environnement de dev a pu être upgrade de 6.3.3 en 6.3.5 sans problème dans le cadre de ce dernier pipeline.

L’environnement d’int ne passe pas de 6.2.22 à 6.3.5.

Lors du démarrage de la webapp, j’ai une erreur bloquante qui interrompt le processus d’upgrade et stoppe le démarrage du pod.

Les seules logs d’erreur dont je dispose sont les suivantes :

J’ai pu passer l’environnement d’int de 6.2.22 à 6.3.3 en utilisant l’ancien pipeline (que j’avais conservé) puis à la 6.3.5 avec le dernier pipeline.

Qu’est-ce qui peut expliquer l’échec de l’upgrade directe d’une 6.2.22 à une 6.3.5 ?

Bonjour Bruno,

Visiblement le patch P03 des ALTER DB n’est pas passé ou pas correctement lors de l’auto upgrade. La colonne obj_search_column est sensée être créée avant de lancer la webapp (et de nombreux autres ordres DDL bloquants si pas installés).

Je ne vois pas ce qui a pu changer dans l’auto-upgrade de la 6.3.5.

Au démarrage Simplicité commence :

  • par checker la version : déjà il faudrait être à jour en 6.2.24 (et non en 6.2.22), normalement il y a un contrôle bloquant qui aurait dû arrêter le process de la 6.3 / param système PATCH_LEVEL pas compatible avec le runtime installé
  • puis il va mettre à jour la base + appliquer les patch XML
  • et enfin recharger la webapp le cache système etc.

On ne voit pas les logs depuis le démarrage donc difficile d’en dire plus à ce stade.

Bonjour François,

merci pour ton retour.

Je n’ai pas beaucoup plus de logs, voir ci-dessous tout ce qui est disponible dans le flux de notre puit de logs.

La plateforme arrête de démarrer en appliquant les patchs (exception dans la séquence d’init ?).

Je termine d’upgrade avec l’oper qui part aussi de la 6.2.22 en allant directement à la 6.3.6. Je reviens vers toi pour confirmer si le problème persiste ou pas. Dans tous les cas je ne devrais pas être bloqué car j’ai conservé mon pipeline intermédiaire via la 6.3.3.

Désolé pour le format d’export mais je n’ai pas trouvé comment exporter ce que je veux (lors du téléchargement des logs, j’ai trop d’infos à l’horizontal et pas assez de lignes en vertical; du coup je reviens au bon vieux screenshot qui montre ce que je veux).



(…moult lignes similaires…)

(…moult lignes similaires…)

Ok merci, le problème bloquant est qu’il ne trouve pas les patchs dans le déploiement :

Patches directory .../ROOT/p01-74196/patches/V6 is not present or is not a directory.

J’escalade le problème, c’est peut-être un problème d’image docker chez nous qui a perdu les patchs.

1 Like

Merci beaucoup pour la prise en compte.

Je confirme que le problème persiste lors d’un upgrade 6.2.22 vers 6.3.6.

ps: oui, j’ai bien noté que nous aurions dû être en 6.2.24 mais j’avais initié le processus d’upgrade début février (◔_◔)

ps2: je confirme que mon upgrade en 6.3.6 (via la 6.3.3) est terminé. Je passe le mot de notre côté de ne pas initier d’upgrade sur d’autres plateformes en attendant d’avoir la confirmation que c’est réglé dans les images docker.

Ok de mon côté, je n’ai rien trouvé de suspect du côté des patchs mais je ne maitrise pas toute la chaine de build jusqu’à vos images.

On attend l’avis de @david qui maitrise mieux que moi ces sujets car ça bouge beaucoup depuis qu’on doit traiter les problèmes de souveraineté, diminuer la voilure des packages/cyber securité, DEV_MODE explicite pour accéder aux fonctions maker, etc.

Le warning “pas de patch trouvés” devrait être bloquant et stopper la JVM. S’il n’y a pas égalité de version et aucun patch livré, il y a aucune chance que ça fonctionne ensuite.

Tu as dû passer par une étape intermédiaire où les anciennes images étaient bien alignées.
A suivre.