[Résolu] - Schedule en erreur de 18.03 vers 19.12

[ymolinet]

To @fblackburn from this another post Upgrade 18.03 to 19.1x (pelican-stretch)

Je suis sur la migration de mes instances Wazo 18.03 vers 19.12 (avant passage en 20.x)
J’ai un problème avec les schedules qui ne passent pas la migration, j’ai ceci dans wazo-ui après la migration (Menu Schedules)

GET https://localhost:9486/1.1/schedules?recurse=False: [“Unexpected error: ‘NoneType’ object has no attribute ‘id’”]

Lien vers le fichier wazo-confd.log:

wazo-confd.log

Je teste la migration sur un serveur sur lequel j’ai restauré la base de données d’une instance de production (18.03)

[fblackburn]

EDIT: Je viens de voir votre dernier ligne (backup/restore). Avez vous le log d’upgrade? Car il y a un gros problème pour ce scenario:
https://wazo-dev.atlassian.net/browse/WAZO-1413

Malheureusement, il n’y a pas d’information dans le log pour savoir d’où vient le soucis
Pour trouver le coupable, vous allez avoir besoin de vous connecter dans la BD

su postgres -c "psql asterisk"

select * from schedule;

Le plus simple pour trouver le coupable, c’est de demander chacune des schedule (avec l’ID ci-dessus) via wazo-ui (ou les API) jusqu’à ce que vous obteniez l’erreur
wazo-ui:

https://<wazo>/engine/schedules/<schedule-id>

Une fois que vous avez trouvé quel schedule est le coupable, vous pouvez essayer de l’effacer via les API (éviter de le faire via la BD)
Si vous voulez vraiment garder cette schedule et corriger le problème, il va me falloir chacun des objet (incall, group, queue, outcall) relié à cette schedule. Si c’est ce que vous voulez, laissez moi le savoir et je vous fournirez les requêtes pour le faire

[ymolinet]

Concernant le bug cité, j’applique les informations fournies ici Upgrade 18.03 to 19.1x (pelican-stretch) - #11 by SIP-Online pour corriger le problème du mot de passe dans wazo-auth-cli qui n’est pas stocké dans le backup.

Voici mon script de restauration de mes bases de données:

#!/bin/bash

wazo-service stop

tar xvfp /root/backups/wazo-data-backup-18.03.tgz -C /
tar xvf /root/backups/wazo-db-backup-18.03.tgz -C /var/tmp
cd /var/tmp/pg-backup
sudo -u postgres psql -c ‘ALTER DATABASE asterisk RENAME TO asterisk_previous’
sudo -u postgres pg_restore -C -d postgres asterisk-*.dump
sudo -u postgres pg_dump -c -t dhcp -t netiface -t resolvconf asterisk_previous | sudo -u postgres psql asterisk
xivo-update-keys
source /etc/profile.d/xivo_uuid.sh
systemctl set-environment XIVO_UUID=$XIVO_UUID
systemctl daemon-reload

dpkg --purge --force-all wazo-auth
rm -r ~/.config/wazo-auth-cli
sudo -u postgres psql -d asterisk -c “DELETE FROM public.auth_user WHERE username = ‘wazo-auth-cli’;”
apt-get install wazo-auth

wazo-service start

Je viens de regarder la table schedule et tester les URL en passant les id.
Il y a trois entrées dans la table, et c’est seulement l’id 1 qui pose problème.
En voulant la supprimer, je vois qu’il y a une clé étrangère vers schedule_path, ce qui m’a permis de voir que le schedule est utilisé par un utilisateur, un groupe, et une file d’attente.
Par rapport à ceux qui fonctionnent, je ne vois pas d’incohérence (caractère spéciaux par exemple)

Pour les schedules que je peux éditer, j’ai constaté que la référence vers les fichiers audio n’était pas maintenu dans wazo-ui alors qu’ils apparaissent dans la base. Je me demande si la table n’aurait pas loupé un upgrade.

Je préférais que l’on trouve la solution pour corriger au cas où cela se produise durant les updates de mes instances de production.

Merci,
Yannick

[fblackburn]

@ymolinet

Concernant le bug cité, j’applique les informations fournies ici Upgrade 18.03 to 19.1x pour corriger le problème du mot de passe dans wazo-auth-cli qui n’est pas stocké dans le backup

Jamais testé cette procédure, seulement testé plusieurs fois le workaround décrit dans le ticket JIRA ci-dessus. Mais si ton upgrade a passé, ca devrait être bon

@ymolinet

En voulant la supprimer, je vois qu’il y a une clé étrangère vers schedule_path, ce qui m’a permis de voir que le schedule est utilisé par un utilisateur, un groupe, et une file d’attente.

Est-ce que tu peux vérifier que le group et la queue qui est rattaché existe bel et bien? Le pathid est l’ID de la ressource. Si la ressource n’existe pas, tu peux supprimer l’entré dans la table schedule_path

@ymolinet

En voulant la supprimer, je vois qu’il y a une clé étrangère vers schedule_path

Tu as essayer de la supprimer directement dans la DB ou passant par les API?

@ymolinet

Pour les schedules que je peux éditer, j’ai constaté que la référence vers les fichiers audio n’était pas maintenu dans wazo-ui alors qu’ils apparaissent dans la base. Je me demande si la table n’aurait pas loupé un upgrade.

Je ne vois pas de quel relation tu parles? Dans les destinations d’heure ouvré fermé?

[ymolinet]

@fblackburn

Tu as essayer de la supprimer directement dans la DB ou passant par les API?

Depuis la base de données directement pour vérifier les implications de clé étrangère. L’utilisateur ne semble plus exister. J’ai supprimer l’entrée en base de données, et c’est tout bon de ce coté là.

@fblackburn

Je ne vois pas de quel relation tu parles? Dans les destinations d’heure ouvré fermé?

Je parle du champs fallback_actionid qui contient le path local vers le fichier audio (fallback_action = sound)

J’en profite pour avoir une information, le changement de version en 19.12 a aussi changer le nom de mes interfaces réseaux sur ma debian (de eno1 vers eth0). Est-ce normal ?

[fblackburn]

@ymolinet

Depuis la base de données directement pour vérifier les implications de clé étrangère. L’utilisateur ne semble plus exister. J’ai supprimer l’entrée en base de données, et c’est tout bon de ce coté là.

Ouais supprimer la relation dans la table schedule_path n’est pas trop risqué pour supprimer les relations. Donc maintenant le list des schedules fonctionne?

@ymolinet

Je parle du champs fallback_actionid qui contient le path local vers le fichier audio (fallback_action = sound)

Dans ce cas, ça se peut que l’interface ai un petit soucis d’affichage. Pour vérifier, tu peux utiliser un API

curl -X GET --header 'Accept: application/json' --header 'X-Auth-Token: <token>' 'https://<host>:9486/1.1/schedules?recurse=false'

Ou tu peux utiliser la documentation interactive sur le site:

Console - Application - Wazo Platform

@ymolinet

J’en profite pour avoir une information, le changement de version en 19.12 a aussi changer le nom de mes interfaces réseaux sur ma debian (de eno1 vers eth0). Est-ce normal ?

Normal? Je sais pas, je crois avoir déjà observé ce comportement lors d’upgrade majeur. De mémoire j’ai pas souvenir qu’on ai fait de code et/ou travaux pour changer explicitement ça.
Sinon je te l’accorde que cette partie là est un peu dommage, car on a aucun moyen de changer cette valeur via des API.
La seule façon de faire est de le faire via la BD dans la table netiface
Pour l’interface dans la table dhcp elle peut etre configuré via l’api /dhcp
Après avoir modifié dans la DB il faut rouler les commandes:

xivo-create-config
xivo-update-config

Attention: c’est de mémoire, mais ça devrait te permettre d’avancer

[ymolinet]

Je vais ajouter un contrôle de cohérence des schedules dans mon script de mise à jour de 18.03 vers 19.12, pour supprimer l’erreur avant la mise à jour. J’ai constaté aussi des erreurs dans les scripts de post-traitement. Avant de travailler dessus, je voulais m’assurer d’avoir résolu ce problème qui peut avoir des conséquences dans l’évolution du schéma de la base de données.

Je te remercie pour ton aide. J’ouvrirai un autre thread si j’ai encore des problèmes.

EDIT : Je confirme qu’en corrigeant la table dans Wazo 18.03, le process de mise à jour vers wazo 19.12 fonctionne parfaitement.