Projet

Général

Profil

Scénario #36142

EOLE 2.10 : Vérifier les messages d'erreur salt dans les logs EAD3

Ajouté par Joël Cuissinat il y a plus d'un an. Mis à jour il y a plus d'un an.

Statut:
Nouveau
Priorité:
Normal
Assigné à:
-
Catégorie:
-
Version cible:
-
Début:
Echéance:
% réalisé:

0%

Points de scénarios:
1.0
Estimation basée sur la vélocité:
Release:
Liens avec la release:
Auto

Description

Dès qu'on utilise l'EAD3, on a cette erreur en boucle dans les logs :

salt.transport.tcp: [ERROR   ] Unhandled exception while running callback <salt.transport.tcp.PublishClient object at 0x7d10febb03d0>#012
Traceback (most recent call last):#012  File "/opt/saltstack/salt/lib/python3.10/site-packages/salt/transport/tcp.py", line 436, in on_recv_handler#012
await callback(msg)#012TypeError: object NoneType can't be used in 'await' expression

Historique

#1 Mis à jour par Benjamin Bohard il y a plus d'un an

J’avais eu l’impression que la mise à jour de rest_eole par Daniel avait corrigé ce problème.

Il y a eu un problème semblable corrigé sur la version 3007.1 (celle actuellement installée).
https://github.com/saltstack/salt/issues/66177

Le callback qui semble renvoyer None serait la méthode handle_event avec le décorateur @tornado.gen.coroutine qui emploie bien un yield.

Mais ce cas précis n’est peut-être pas le seul déclenchant le type d’erreur observé. Lors d’un rafraîchissement d’une action dans l’EAD3, on observe plusieurs fois cette erreur (jusqu’à 8 observées).

On reproduit l’erreur en lançant une commande salt-call :

/opt/saltstack/salt/salt-call -c /etc/ead3/salt/ network.interfaces

L’erreur est déclenchée trois fois dans ce cas mais la commande renvoie bien le résultat.

#2 Mis à jour par Benjamin Bohard il y a plus d'un an

Le problème n’est, en fait, reproductible avec la commande salt-call que si il est d’abord déclenché en interagissant avec l’EAD3.
Lancée immédiatement après le redémarrage de l’api et du minion, la commande salt-call ne déclenche pas les erreurs mais il semble qu’en attendant un peu, on finisse bien par les observer.

#3 Mis à jour par Benjamin Bohard il y a plus d'un an

Logiquement, dans le premier cas, salt-call ne passe pas par l’api et ne déclenche donc pas d’erreur.
Moins logiquement, les erreurs de l’api semblent déclenchées par des appels ultérieurs à salt-call.

#4 Mis à jour par Benjamin Bohard il y a plus d'un an

Exemple d’appel direct à l’api (sans passer par l’interface EAD3)

curl -sS localhost:8880/run -H 'Accept: application/x-yaml' -d client='local' -d fun='ead.majreport_read' -d tgt='local' -d username='eole' -d password='eole' -d eauth='pam'

#5 Mis à jour par Joël Cuissinat il y a plus d'un an

  • Sujet changé de Vérifier message d'erreur dans les logs à EOLE 2.10 : Vérifier les messages d'erreur salt dans les logs EAD3
  • Tâche parente #35851 supprimé
  • Release mis à EOLE 2.10.0
  • Points de scénarios mis à 1.0

#6 Mis à jour par Joël Cuissinat il y a plus d'un an

  • Tracker changé de Tâche à Scénario
  • Version cible Carnet Cadoles - MEN supprimé
  • Début 29/08/2024 supprimé

Formats disponibles : Atom PDF