l3-fs-readonly-recover : reset impossible en séquence (hôte injoignable), et son cleanup laisse un marqueur

[stephrobert]

Symptôme

Campagne de validation du 27/07 à 14:20, solution/verified-with.json :

"l3-fs-readonly-recover": {
  "etat": "ignoré",
  "motif": "reset impossible : status=failed). Stats : {'skipped': {}, 'ok': {'alma-rhcsa-1.lab': 2}, 'dark':"
}

Le lab n'a même pas pu être remis à l'état initial : il a donc été sauté, sans être validé ni invalidé. Il était vert dans la campagne de 11:46 le même jour (4 passed in 2.90s).

dark est le vocabulaire d'Ansible pour un hôte injoignable. Deux tâches ont réussi sur alma-rhcsa-1.lab, puis la machine a cessé de répondre. Le motif est tronqué dans le JSON, ce qui empêche de savoir quel hôte est passé en dark et sur quelle tâche.

Deux problèmes distincts, à ne pas confondre

1. L'hôte devient injoignable pendant la séquence

C'est le problème bloquant, et il n'est pas propre à ce lab : une VM qui cesse de répondre en cours de campagne peut avoir été cassée par n'importe quel lab précédent. Ce lab est simplement le premier à en subir les conséquences.

Ce qui rend la piste crédible pour ce lab en particulier : son setup.yaml manipule /etc/fstab sur le disque additionnel et y monte un système de fichiers en lecture seule. Une entrée fstab fautive laissée en place peut empêcher un redémarrage d'aboutir. Le lab suivant dans le meta.yml est l3-ssh-access-recovery, qui touche justement à l'accès SSH.

À noter que le cleanup.yaml retire bien la ligne /srv/data de /etc/fstab, y compris quand /root/fsro-disk.env n'existe pas : ce n'est donc pas la piste la plus évidente. Il faut la sortie réelle.

2. Le cleanup.yaml ne supprime pas /root/fsro-disk.env

Celui-ci est certain, vérifié par lecture. Le setup.yaml se garde avec deux marqueurs :

creates: /root/fsro-disk.env     # ligne 32
creates: /root/.fsro-ready       # ligne 55

Le cleanup.yaml n'en efface qu'un :

rm -f /root/.fsro-ready

Il lit pourtant /root/fsro-disk.env deux fois ([ -f ... ] || exit 0 puis . /root/fsro-disk.env), mais ne l'efface jamais. Après un nettoyage, ce fichier survit donc, et la tâche « Detect the additional block device » est sautée au setup suivant : le lab repart sur la valeur de DISK héritée du passage précédent, au lieu de redétecter le disque.

C'est exactement la règle que tests/test_marqueurs_setup_cleanup.py est censé faire respecter (« ce qu'un creates: protège, un cleanup doit le rendre »), et il ne l'attrape pas. La raison est un défaut du test lui-même, ouvert séparément : il exige que le chemin soit mentionné, pas qu'il soit supprimé.

Correctif, quelle que soit l'issue de l'enquête sur le point 1 :

-          rm -f /root/.fsro-ready
+          rm -f /root/.fsro-ready /root/fsro-disk.env

Comment trancher le point 1

L'échec était muet. Deux correctifs mergés depuis rendent la prochaine campagne parlante : #46 (la sortie complète est conservée dans le JSON) et #42 (le message de la fixture porte la sortie du playbook).

Le motif tronqué à 'dark': est en soi un défaut de l'outil : il coupe l'information juste avant le nom de l'hôte concerné, qui est précisément ce qu'on cherche.

Critères d'acceptation

• /root/fsro-disk.env est supprimé par le cleanup.yaml.
• La cause de l'hôte injoignable est identifiée à partir d'une sortie réelle, et le lab responsable est corrigé (ce n'est pas nécessairement celui-ci).
• Le motif enregistré dans verified-with.json n'est plus tronqué avant l'information utile.
• Le lab passe au vert en séquence complète.