GeoNature
GeoNature copied to clipboard
PnX-SI
Soucis sur migration.sh
Version Toutes. Par exemple passage de 2.75 à la 2.9.2
Description du bug
Lors de la migration de geonature avec le migration.sh, il y a un soucis si le ou les fichiers de config nécessitent un changement.
En effet, ils sont récupérés tel que depuis le répertoire geonature_old. Mais si ces fichiers de config nécessitent le retrait ou l'ajout d'un paramètre nécessaire ou incompatible avec la nouvelle version, le migration.sh poursuit l'installation de GeoNature qui va planter.
Comportement attendue Ben pas facile à gérer ! Peut_être un stop durant le processus pour mettre à jour le ou les fichiers. OU Faire en 3 étapes,
- récupérer les config dans un premier fichier. STOP et indiquer de faire un check.
- Contrôle et/ou modif manuelles si nécessaire des configs
- 2ème fichier de migration
Comment reproduire
Tenter un passage de la 2.7.5 à la 2.9.2
Le param MAIL_DEBUG dans [MAIL_CONFIG] et le param LOG_API ne passent pas en 2.9.2
Dans la conf d'occtax la colonne sample_number_proof n'est plus acceptée en 2.9.2
Sauf erreur de ma part, ces infos ne figurent pas dans les notes de versions.
Tu lances le migration.sh, ça plante et tu comprends alors en lisant les erreurs qu'il faut modifier les fichiers de config. Sauf que si tu les modifies et que tu relances migration.sh, tes modifications sont écrasées par le script qui va reprendre les anciens scripts tel que dans geonature_old. Le contournement est de modifier la config dans geonature_old avant de lancer migration.sh mais ce n'est pas bien clean si tu dois revenir en arrière.
A noter aussi que le migration .sh migre la base de données et qu'il n'est donc pas très simple de revenir en arrière si nécessaire.
On a fait plusieurs migrations de 2.7 à 2.9 sans rencontrer ce soucis. A voir pourquoi.
Les param obsolètes remontaient peut-être a des versions antérieures. A voir comment gérer ces situations.
rencontré aussi sur des paramètres comme les id_type des zonages etc notamment quand c'est personnalisé, qu'on a des listes etc.
La note de version ou la procédure devrait peut être expliciter si besoin qu'il faut d'abord appliquer les notes de version et notamment mettre à jour les fichiers de conf avant de lancer le migrate.sh, de cette manière on a pas le soucis.
Il faut bien préciser que la mise à jour de la conf est à faire dans le geonature_old. Ainsi ça fonctionnera mais si besoin de revenir sur la version du geonature_old, la conf aura été modifiée. Si la migration est automatisée, il faut peut être essayer d'automatiser aussi la mise à jour de la conf afin de s'assurer qu'elle est compatible avec l'installation de la nouvelle version qui en découle. Ou au moins tester la validité de la conf avant de lancer des actions modificatives. Sinon tu te retrouves dans un état intermédiaire et tu ne sais pas comment reprendre la migration.
Je pense qu'il faudrait voir pour que la migration ne plante pas si un paramètre a évolué. D'ailleurs j'ai du mal à capter pourquoi une évolution d'un paramètre fait planter la migration.
Mais dans tous les cas, les modifications de paramètre sont à faire avant de lancer le script migration.sh qui est la dernière étape. Peut-être à indiquer dans la doc (https://docs.geonature.fr/installation.html#mise-a-jour-de-l-application).
PS : Depuis que la mise à jour de la BDD est automatisée avec Alembic, cela facilite aussi le retour en arrière, car chaque migration Alembic contient la procédure d'upgrade mais aussi celle de downgrade pour revenir en arrière si besoin.
D'ailleurs j'ai du mal à capter pourquoi une évolution d'un paramètre fait planter la migration.
De mémoire, les fichiers toml sont contrôlés par Marshmallow. Je n'ai pas vérifié mais il y a je crois comme un schéma qui décrit les paramètres existants. Si les param obsolètes sont retirés de ce schéma mais que l'un d'eux reste dans le fichier toml, Marshmallow lève une erreur. A vérifier