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

Support
1

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 :

image
image1660×329 86.9 KB

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 ?

2

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.

3

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).

image
image1651×1028 282 KB

image
image1651×1045 274 KB

(…moult lignes similaires…)
image
image1651×1051 287 KB

(…moult lignes similaires…)
image
image1651×463 121 KB

4

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.

6

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.

7

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.

9

Bonjour

Pour investiguer plus précisément j’aurais besoin de la version exacte de la base de données utilisée.

Car, en l’état, sur une base de données PostgreSQL à jour (18.3) je ne constate pas de problème en upgradant une instance “out of the box” 6.2.22 vers 6.3.5

Avant:

image
image1147×495 44.7 KB

Après:

image
image1169×498 46 KB

PS: il n’y a pas non plus de problème en upgradant une instance “out of the box” 6.2 à jour (i.e. 6.2.24) vers 6.3 à jour (i.e. 6.3.6)

Voici, pour mémoire, le descripteur docker compose utilisé pour les tests:

services:
  postgresql:
    image: postgres:latest
    restart: unless-stopped
    container_name: test_postgresql
    environment:
      TZ: "Europe/Paris"
      PGTZ: "Europe/Paris"
      POSTGRES_USER: "xxx"
      POSTGRES_PASSWORD: "xxx"
      POSTGRES_DB: "xxx"
    volumes:
      - postgresql_data:/var/lib/postgresql
  simplicite:
    image: registry.simplicite.io/platform:6.2.22 (puis 6.3.5)
    restart: unless-stopped
    container_name: test
    user: simplicite
    environment:
      TOMCAT_TIMEZONE: "Europe/Paris"
      DB_SETUP: "true"
      DB_VENDOR: "postgresql"
      DB_HOST: "test_postgresql"
      DB_USER: "xxx"
      DB_PASSWORD: "xxx"
      DB_NAME: "xxx"
      DB_WAIT: 100
      DB_WAIT_INTERVAL: 10
    ports:
      - 127.0.0.1:8443:8443
    depends_on:
      - postgresql
volumes:
  postgresql_data:
10

PS:

image

Je ne m’explique pas la présence du sous répertoire p01-74196 qu’on voit dans tes logs (cf. ci-dessus) et qui fait que les fichiers patches ne sont pas trouvés.

Il me faudrait donc les descripteurs de démarrage complets de l’instance pour comprendre la cause…

11

Bonjour David,

merci beaucoup pour ton support.

Je pense que ça vient de là :

image
image1635×107 16 KB

J’essaye de remonter l’historique pour voir depuis combien de temps c’est là…

12

C’est moi le mauvais…

image

Ajouté après avoir initié le pipeline pour l’upgrade en 6.3.3 qui n’a donc pas ce paramètre alors que le dernier déploiement en 6.3.5 l’a…

Quels sont les autres impacts de cet ajout (`-Dapplication.name=…`) ? Si je l’ai ajouté c’est que ça m’avait semblé utile/nécessaire mais j’ai été manifestement interrompu sur ma lancée et je n’ai plus les éléments de contexte. De mémoire, je tirai les instructions du guide de sécurisation et je testais différentes configurations.

13

Ok ça s’explique car le répertoire patches est relatif au “project dir” qui utilise la property JVM application.name si celle-ci est présente

Rien de nouveau à ce niveau, j’ai vérifié c’était déjà comme ça en v5 (et je pens en v4, voire en v3 je n’ai pas vérifié)

On va regarder pour mieux gérer ce cas = sortir en erreur fatale (donc pas de démarrage de la webapp) si le répertoire patches n’existe pas pendant la phase d’auto upgrade du démarrage plutôt que de démarrer non patché

14

Il y a plusieurs répertoires de travail (src, bin, build, jar, …) qui sont relatifs au “project dir” ça ne doit pas poser de pb car ils sont créés si besoin à la volée.

Par contre le répertoire des patches (SQL et XML) doit pouvoir être trouvé dans tous les cas, du coup il ne devrait peut être pas être relatif au “project dir” (j’avoue ne plus me rappeler pourquoi c’est le cas) et, comme proposé plus haut, son absence devrait finir en erreur fatale au démarrage.

On va creuser tout ça. En attendant la “solution” est de ne pas mettre cette property JVM application.name. Il faudrait voir ce qui avait justifié de l’ajouter pour déterminer quelle serait la bonne stratégie pour mieux répondre au besoin

15

Merci pour le retour. D’après ce que je comprends, si le répertoire de patches ne dépend pas du “project dir”, il ne devrait plus y avoir de problème dans mon cas. Comme je ne sais plus pourquoi j’ai ajouté ce paramètre (je vais chercher)…

En attendant que je détermine ce qui m’avait maené à ajouter ça, quel serait l’impact d’ajouter la création d’un lien ou de dupliquer les patches lors de la composition de l’image ? (COPY .../ROOT/WEB-INF/patches .../ROOT/WEB-INF/p01-74196)

17

On a revu la manière dont est déterminé l’emplacement du répertoire des patches, ça ne tiendra plus compte de la property application.name.

L’absence des patches provoquera aussi désormais une erreur fatale lors de l’auto upgrade = empêchera la webapp de démarrer

Ce sera livré dans la prochaine révision 6.3.7 (et c’est disponible dès à présent dans l’image 6-preview pour tester en avance de phase si besoin) ce sera backporté sur les versions en maintenance (6.2 et 5.3) ultérieurement