Projet

Général

Profil

Development #29965

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

Ajouté par Emmanuel Cazenave il y a environ 5 ans. Mis à jour il y a presque 5 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
22 janvier 2019
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:

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

Fichiers


Demandes liées

Lié à Passerelle - Development #28637: Logguer quand même en DB lorsqu'un connecteur est 'down' Rejeté05 décembre 2018

Actions

Révisions associées

Révision fa76fbc8 (diff)
Ajouté par Emmanuel Cazenave il y a environ 5 ans

manage availability check through the UI (#29965)

Historique

#1

Mis à jour par Emmanuel Cazenave il y a environ 5 ans

  • Lié à Development #28637: Logguer quand même en DB lorsqu'un connecteur est 'down' ajouté
#2

Mis à jour par Frédéric Péters il y a environ 5 ans

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

Mis à jour par Emmanuel Cazenave il y a environ 5 ans

Je trouverais ça beaucoup moins pratique.

#4

Mis à jour par Frédéric Péters il y a environ 5 ans

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

Mis à jour par Emmanuel Cazenave il y a environ 5 ans

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

Mis à jour par Emmanuel Cazenave il y a environ 5 ans

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

Mis à jour par Emmanuel Cazenave il y a environ 5 ans

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

Mis à jour par Frédéric Péters il y a environ 5 ans

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

Mis à jour par Emmanuel Cazenave il y a environ 5 ans

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

Mis à jour par Frédéric Péters il y a environ 5 ans

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

Mis à jour par Emmanuel Cazenave il y a environ 5 ans

Ok merci pour les explications.

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

#12

Mis à jour par Christophe Siraut il y a environ 5 ans

  • Statut changé de Solution proposée à Solution validée
#13

Mis à jour par Emmanuel Cazenave il y a environ 5 ans

  • Statut changé de Solution validée à 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

Mis à jour par Frédéric Péters il y a environ 5 ans

  • Statut changé de Résolu (à déployer) à Solution déployée
#15

Mis à jour par Benjamin Dauvergne il y a presque 5 ans

  • Statut changé de Solution déployée à Fermé

Formats disponibles : Atom PDF