Project

General

Profile

Development #29965

Débrayer la vérification de disponibilité d'un connecteur

Added by Emmanuel Cazenave 9 months ago. Updated 6 months ago.

Status:
Fermé
Priority:
Normal
Target version:
-
Start date:
22 Jan 2019
Due date:
% Done:

0%

Patch proposed:
Yes
Planning:
No

Description

Lorsque le test de disponibilité s'avère instable, il serait commode de pouvoir débrayer le test de disponibilité dans l'UI et ainsi obtenir des logs.
Utile dans une phase de prototypage, ou en prod pour un diagnostique de dysfonctionnement.

J'imagine le comportement suivant :

  • débrayer le test de disponibilité force le statut à 'up' et annihile les test de disponibilité
  • annuler le débrayage ne touche pas au statut et rétablit l'éligibilité aux tests de dispo

0001-manage-availability-check-through-the-UI-29965.patch View (12.9 KB) Emmanuel Cazenave, 05 Feb 2019 03:39 PM

Screenshot-2019-2-5 Passerelle(1).png View (8.48 KB) Emmanuel Cazenave, 05 Feb 2019 03:39 PM

Screenshot-2019-2-5 Passerelle.png View (131 KB) Emmanuel Cazenave, 05 Feb 2019 03:39 PM

0002-remove-default-check_status-29965.patch View (3 KB) Emmanuel Cazenave, 11 Feb 2019 05:15 PM

0001-manage-availability-check-through-the-UI-29965.patch View (14.6 KB) Emmanuel Cazenave, 11 Feb 2019 05:15 PM

31507
31508

Related issues

Related to Passerelle - Development #28637: Logguer quand même en DB lorsqu'un connecteur est 'down' Rejeté 05 Dec 2018

Associated revisions

Revision fa76fbc8 (diff)
Added by Emmanuel Cazenave 8 months ago

manage availability check through the UI (#29965)

History

#1 Updated by Emmanuel Cazenave 9 months ago

  • Related to Development #28637: Logguer quand même en DB lorsqu'un connecteur est 'down' added

#2 Updated by Frédéric Péters 9 months ago

Lorsque le test de disponibilité s'avère instable, il serait commode de pouvoir débrayer le test de disponibilité dans l'UI et ainsi obtenir des logs.

Pas tellement envie de charger l'UI avec ça; ça ne pourrait pas simplement être un settings global ?

#3 Updated by Emmanuel Cazenave 9 months ago

Je trouverais ça beaucoup moins pratique.

#4 Updated by Frédéric Péters 9 months ago

Je trouverais ça beaucoup moins pratique.

Parce que tu es la personne qui sur le moment a besoin de cette option. Pour toutes les autres personnes qui ajouteraient/modifieraient un connecteur, ça ferait une case à cocher en plus.

#5 Updated by Emmanuel Cazenave 9 months ago

En fait je n'imaginais pas ça sur la page d'édition principale du connecteur, mais dans une popup qui s'ouvrait à partir d'un lien figurant à droite de 'paramètres de journalisation'.

Pour aller jusqu'au bout de l'idée, je pensais un nouveau champ booléen force_up sur ResourceStatus, par défaut à False, qui peut facilement influer les méthodes up and down et être utilisé dans availability pour zapper le check_status.

Et donc la popup serait une simple checkbox d'édition de ce champ.

#6 Updated by Emmanuel Cazenave 9 months ago

Loupé le fait qu'on écrit successivement des ResourcesStatus, je pensais qu'il y en avait qu'un par connecteur, donc le flag serait sur l'objet connecteur, ce qui n'empêche pas de l'éditer ailleurs que sur la page d'édition principale.

#7 Updated by Emmanuel Cazenave 8 months ago

31507
31508

Finalement je stocke ce flag disable_check dans un modèle à part AvailibityParameters, dans l'idée qu'on pourra vouloir y rajouter un pilotage plus fin de la disponibilité, genre périodicité des tests ou que sais-je.

Si le flag est mis à True, plus de tests de dispos, et le connecteur passe à 'up' si il était 'down' (on pourrait aussi plus tard donner le choix à l'utilisateur sur le statut cible en cas de débrayage du suivi).

Coté UI, cf captures, une nouvelle entrée de le menu, qui ne s'affiche que sur les connecteurs où des tests de disponibilité ont déjà eu lieu. Je voulais faire un truc plus joli avec un couple d'icônes à la place du texte 'manage availability' qui aurait indiqué tout de suite l'état actif ou non du suivi de disponibilité, mais je me suis perdu dans font-awesome et gadjo.

#8 Updated by Frédéric Péters 8 months ago

Plutôt "availability check" comme libellé de bouton; et plutôt formuler l'option dans le sens inverse (option qui s'appellerait "Run regular availability checks", cochée par défaut); peut-être avec un help_text qui dit que ça tourne toutes les x minutes ?

Histoire de ne pas trainer ça pendant des années, corriger dès maintenant le nom du modèle (availibity vs availability).

qui ne s'affiche que sur les connecteurs où des tests de disponibilité ont déjà eu lieu

Je l'afficherais sur les connecteurs où les tests de disponibilité sont possibles. (genre ajouter un attribut à la méthode check_status de la classe de base, pour différencier facilement cette méthode de celles définies pour faire vraiment quelque chose).

            resource.logger.info(
                u'connector "%s" (%s) put back up by user', resource, resource.__class__.__name__)

Je logguerais simplement "availability reports enabled (ou disabled)", peu importe si c'était connu down, ou pas.

#9 Updated by Emmanuel Cazenave 8 months ago

Toutes les remarques prises en compte dans 0001-manage-availability-check-through-the-UI-29965.patch.

0002-remove-default-check_status-29965.patch optionnel : simplifie la discrimination entre connecteurs qui implémentent check_status et les autres (à la lecture du patch de #9416, je ne vois pas la nécessite de check_status sur BaseResource, donc autant simplifier plutôt que de rajouter un attribut sur la méthode me suis-je dit).

#10 Updated by Frédéric Péters 8 months ago

0002-remove-default-check_status-29965.patch optionnel : simplifie la discrimination entre connecteurs qui implémentent check_status et les autres (à la lecture du patch de #9416, je ne vois pas la nécessite de check_status sur BaseResource, donc autant simplifier plutôt que de rajouter un attribut sur la méthode me suis-je dit).

De mon côté j'aime bien que la classe de base puisse décrire les méthodes attendues; ailleurs (combo), pour des raisons de performances, on fait sans mais on garde quand même un attribut, à None, exemple :

     # get_badge(self, context); set to None so cell types can be skipped easily
    get_badge = None

(ce qui retirerait la nécessité d'hasattr, ce qui est toujours mieux)

Bref, sur 0002, j'aime bien sans, que la méthode soit clairement présente; mais si on veut la retirer qu'un attribut None prenne sa place, que ça permettre de retirer de l'hasattr.

#11 Updated by Emmanuel Cazenave 8 months ago

Ok merci pour les explications.

Restons en à l'essentiel, oublions 0002-remove-default-check_status-29965.patch.

#12 Updated by Christophe Siraut 8 months ago

  • Status changed from Solution proposée to Solution validée

#13 Updated by Emmanuel Cazenave 8 months ago

  • Status changed from Solution validée to Résolu (à déployer)
commit fa76fbc8d7a0576eb94ff16cc5f6161e1c8fec68
Author: Emmanuel Cazenave <ecazenave@entrouvert.com>
Date:   Tue Jan 22 14:34:56 2019 +0100

    manage availability check through the UI (#29965)

#14 Updated by Frédéric Péters 8 months ago

  • Status changed from Résolu (à déployer) to Solution déployée

#15 Updated by Benjamin Dauvergne 6 months ago

  • Status changed from Solution déployée to Fermé

Also available in: Atom PDF