Produits Entr'ouvert » Passerelle

Cela remplacerait l'alerte par email qui existe déjà,

Subject: [passerelle.etc.] ERROR: connector "Envoi de SMS (via OVH)" (OVHSMSGateway) is now down: OVH error: POST failed, ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))
To: ...

connector "Envoi de SMS (via OVH)" (OVHSMSGateway) is now down: OVH error: POST failed, ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))

Report connector "Envoi de SMS (via OVH)" (OVHSMSGateway) is now down: OVH error: POST failed, ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))

(...)

i.e. dans passerelle/base/models.py set_availability_status remplacer les appels au système de logging par des emails explicites.

une input pour indiquer les plages de dispo prévues, genre 2-23 pour dire de n'envoyer ces infos qu'entre 2h et 23h (dans le cas d'un logiciel qui est rebouté chaque nuit, c'est si typique)

Dans le système actuel il y a également possibilité de configurations de délais (pour par exemple s'éviter les notifications pour les "micro-coupures") et de répétitions (notification_delays).

J'ai un début de proposition mais aussi quelques doutes.

En fait la configuration des délais fonctionne ainsi. Quand un connecteur devient "down":

- soit on a "0", valeur par défaut, et la notification est envoyée une fois immédiatement puis plus jamais

- soit on a une valeur autre type "10" ou "0,5,10" et la notification est envoyée régulièrement (la suite de la liste est calculée en fonction du dernier delai: "10,20,30,40..." / "0,5,10,20,30,40...")

Je trouve le cas particulier 0 un peu surprenant. A la place je proposerai bien que:

- soit on a un unique délai indiqué "5" / "10" et une notification est envoyée une unique fois après ce délai. Voir peut-être mettre 5 par défaut, qui est l'intervalle entre deux cron et éviterai les notif en cas de "micro" coupure.

- soit on a une liste de valeurs et le comportement reste celui actuelle

Aussi, j'ai considéré que maintenant qu'on a un affichage des donwtimes dans l'UI on a plus besoin d'ajouter des ResourceLog qui indique seulement "c'est down depuis {duration}". C'est discutable et je suis preneur d'éventuelles contradictions.

Gael Pasgrimaud a écrit :

- soit on a un unique délai indiqué "5" / "10" et une notification est envoyée une unique fois après ce délai. Voir peut-être mettre 5 par défaut, qui est l'intervalle entre deux cron et éviterai les notif en cas de "micro" coupure.

Ça ne me dérangerait pas qu'on aille vers ça avec un délai par défaut de 1 minute, le cron tournant moins vite que on aura par défaut une alerte si deux check d'affilé échouent, et pour adapter les configurations actuelles prendre la dernière valeur ?

Aussi, j'ai considéré que maintenant qu'on a un affichage des donwtimes dans l'UI on a plus besoin d'ajouter des ResourceLog qui indique seulement "c'est down depuis {duration}".

D'accord avec ça.

Benjamin Dauvergne a écrit :

et pour adapter les configurations actuelles prendre la dernière valeur ?

Je ne vois pas ce que tu veux dire. Pour moi il n'y a rien à adapter. Si la configuration est à "0", ça marche. Si c'est problématique, ça se change à la main. Si c'est autre chose que 0, c'est très bien aussi.

Je zappe un truc ?

J'ai fini par comprendre ce que tu voulais dire (si on a 5, générer 5,10,..). Mais je serai pour ne pas le faire.

De ce que je vois il n'y a que deux connecteurs qui utilise une seule valeur différente de 0 en prod:

- sur passerelle_eservices_toulouse_metropole_fr un délai est à 60

- sur passerelle_mesdemarches_labaule_fr un délai est à 1. Du coup ils (ou on) se prennent un paquet de notif ?

Il suffirait de changer ces deux valeurs (rajouter ,XX) pour que ça reste conforme au fonctionnement actuel

Et je continue de penser que de permettre de n'avoir qu'une notif quand on le désir, c'est pas mal. La majorité des cas semble être à 0 (voir ne pas envoyer de notifs du tout)

Aussi, en faisant cette recherche, j'ai repéré un tenant qui ne semble pas avoir la table. Je trouve ça louche: ERROR: relation "passerelle_mesdemarches_departement06_fr.base_availabilityparameters" does not exist

Gael Pasgrimaud a écrit :

Aussi, en faisant cette recherche, j'ai repéré un tenant qui ne semble pas avoir la table. Je trouve ça louche: ERROR: relation "passerelle_mesdemarches_departement06_fr.base_availabilityparameters" does not exist

C'est une instance obsolète, l'instance est maintenant sur le SaaS HDS et s'appelle passerelle_mesdemarches06_fr.