---
# Supervision derivee du role. Voir docs/supervision-conception.md.
#
# CE QUE `serveur_artefacts` SURVEILLE DEJA, ET QU'ON NE REFAIT PAS : `cache-apt` (le
# cache repond sur son port) et `cache-apt-volume` (il lui reste de la place). Ces deux
# verdicts valent pour N'IMPORTE QUEL cache de la fabric.
#
# CE ROLE PORTE UNE AUTRE VERITE, ET ELLE N'EST VRAIE QUE POUR LUI : ce cache est la
# RACINE de la chaine. Aucun autre n'a Debian comme amont direct.
#
#     VM du tenant  ->  cache du tenant  ->  cache du SITE  ->  Debian
#
# Deux choses peuvent cesser d'etre vraies sans que rien ne tombe :
#
#   1. LA RACINE SE RETROUVE CHAINEE. Quelqu'un configure un mandataire amont sur ce
#      cache — et la chaine se referme sur elle-meme ou sur un cache qui n'existe plus.
#      `tasks/main.yml` l'exige au deploiement ; plus personne ne le verifie ensuite.
#
#   2. LA RACINE NE REMPLIT PLUS. Le cache repond parfaitement — il sert ce qu'il a — et
#      ne peut plus rien chercher chez Debian. `cache-apt` reste VERT.
#
# CE QUE LE FLUX DE CE ROLE DIT DEJA, MOT POUR MOT : sans sortie, « la chaine entiere se
# termine sur un cache vide [...] et ca ne se serait vu qu'au premier `apt update` d'un
# ecosysteme neuf — c'est-a-dire au pire moment ». La sonde deplace ce constat AVANT
# l'installation d'un locataire, au lieu de le laisser arriver pendant.
#
# TTL de 5400 s pour un porteur qui passe aux 15 min : trois passages manques avant la
# peremption. Le silence alerte autant que l'echec.
sondes:
  - nom: cache-site-racine
    ttl: 5400
    raison: 'Ce cache est-il toujours la RACINE de la chaine, et peut-il encore remplir ?
      Un cache chaine sur lui-meme ou coupe de Debian repond parfaitement — il sert ce
      qu''il a deja. La panne n''apparait qu''au premier `apt update` d''un ecosysteme
      neuf, c''est-a-dire au pire moment.'