diff --git a/CHANGELOG.md b/CHANGELOG.md index 360e301..3a898e5 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,52 @@ # CHANGELOG — Set-OPS +## 2026-09-20 (5) — Celui qui pousse avance son propre clone + +**82 preuves dans le rapport du 17 septembre, non rejouées ici.** Le correctif de +l'entrée `(4)` attendait sa preuve : il l'a eue en conditions réelles, et en la donnant +il a montré le cas qu'il ne couvrait pas. + +### Le déclenchement, mesuré deux fois + +Le commit `f9a20b0` poussé sur la forge du site, rejouer `serveur_ops` chez les deux +locataires a fait avancer leur clone de `6367d85` à `f9a20b0`. La tâche +« Redémarrer la console quand le moteur a avancé » est passée en `changed` sur les deux : +console de TechnoLibre repartie à 15h33m33 contre 15h16m49, celle de Chezlepro à 15h38m02 +contre 15h16m47. Les deux sondes rendent 0. **Le mécanisme a été vu fonctionner, pas +simulé** — et la tâche s'était abstenue plus tôt le même jour, quand les clones étaient +déjà au niveau de la forge. + +### Le site ne peut pas se voir avancer + +`genome_pousser.yml` fait avancer le clone du runner du site **sans qu'aucun rôle ne +passe** : c'est lui qui pousse, donc il doit d'abord recevoir. Mesure du même jour — son +clone est passé à `f9a20b0` pendant la poussée, sa console est restée démarrée à 15h16. +Le correctif de `serveur_ops` ne peut rien pour lui : quand le rôle passera, le clone sera +déjà à jour, et la tâche s'abstiendra à juste titre. L'hébergeur gardait donc précisément +le défaut corrigé chez ses locataires. + +Le remède tient là où vit la cause. Le playbook nomme déjà la transition dans son verdict +(`6367d85 → f9a20b0`) : il en tire maintenant la conséquence et redémarre la console du +site quand c'est **le moteur** qui a bougé. Un plan poussé ne coupe pas les pages +ouvertes, et un runner sans console n'est pas touché — l'unité systemd est vérifiée avant. + +**Personne d'autre que ce playbook ne sait que ce clone a avancé.** Une information qui +n'existe qu'à un endroit doit y être utilisée, sinon elle se perd et le défaut se +reconstitue au passage suivant. + +### Ce qui a été vérifié, et ce qui ne l'a pas été + +`--syntax-check` sur `playbooks/maintenance/genome_pousser.yml`, contre l'inventaire du +site et contre celui d'un locataire ; `ansible-lint` sur le playbook (profil `production`, +0 échec, 0 avertissement). La condition de déclenchement est éprouvée sur quatre cas : +moteur avancé, moteur immobile, `DEPOT=` visant un plan seulement, et la boucle sans +résultat du mode `--check`. + +**Le redémarrage de la console du site n'a pas encore été observé** : il demande une +poussée du génome postérieure à ce commit. La console du site sert donc encore, à +l'heure où ces lignes sont écrites, le code chargé à 15h16 — le disque, lui, porte +`f9a20b0`. Aucune preuve du harnais rejouée, aucune voûte ouverte, aucune VM touchée. + ## 2026-09-20 (4) — Le code sur le disque n'est pas le code servi **82 preuves dans le rapport du 17 septembre, non rejouées ici.** Les trois runners @@ -62,9 +109,10 @@ rendu dans ses deux modes, sans reste Jinja, et passe `bash -n` ; son filtre d' éprouvé sur cinq formes d'adresses réelles. Le rôle est appliqué aux trois runners et la sonde rejouée sur chacun. -**Le redémarrage automatique n'a pas été observé en conditions réelles** : les clones -étaient déjà au niveau de la forge, la tâche s'est donc correctement abstenue. La preuve -du déclenchement viendra au prochain génome poussé. Les trois consoles ont été redémarrées +**Le redémarrage automatique n'était pas observé au moment d'écrire ces lignes** : les +clones étaient déjà au niveau de la forge, la tâche s'est donc correctement abstenue. +La preuve est venue le jour même, une fois ce commit poussé sur la forge du site — elle +est mesurée dans l'entrée `(5)` ci-dessus. Les trois consoles ont été redémarrées à la main ce jour-là pour servir le code courant. Aucune preuve du harnais n'a été rejouée, aucune voûte ouverte, aucune VM créée ou détruite. diff --git a/playbooks/maintenance/genome_pousser.yml b/playbooks/maintenance/genome_pousser.yml index 2afaa34..d0880a0 100644 --- a/playbooks/maintenance/genome_pousser.yml +++ b/playbooks/maintenance/genome_pousser.yml @@ -255,6 +255,42 @@ label: "{{ item.depot }}" index_var: idx + # LE RUNNER DU SITE AVANCE SON PROPRE CLONE, ET SA CONSOLE NE LE SAIT PAS (2026-09-20). + # + # C'est LUI qui pousse, donc il doit d'abord recevoir : ce playbook fait avancer le + # moteur du site sans qu'aucun role ne passe. `serveur_ops` redemarre bien la console + # quand le clone avance, mais il ne verra jamais cet avancement-ci — le clone sera + # deja a jour quand il passera. Le site garderait donc une console servant l'ancien + # code, exactement le defaut corrige le meme jour chez les locataires. + # + # `python3 scripts/inventory_gui.py` lit son code au demarrage, et seulement la. Ce + # qui a avance doit etre relu, et personne d'autre que ce playbook ne sait qu'il a + # avance : le verdict ci-dessus nomme la transition, il suffit de l'ecouter. + - name: Retenir ce que le colis du moteur a fait bouger + ansible.builtin.set_fact: + genome_moteur_colis: >- + {{ (genome_recu.results | default([])) + | selectattr('item.dest', 'equalto', genome_moteur) + | map(attribute='stdout') | list }} + + - name: Voir si ce runner sert une console + ansible.builtin.stat: + path: /etc/systemd/system/setops-gui.service + register: genome_console_unite + + - name: Redémarrer la console du site quand son moteur a avancé + ansible.builtin.systemd: + name: setops-gui.service + state: restarted + daemon_reload: true + become: true + become_user: root + when: + - genome_console_unite.stat.exists + - genome_moteur_colis | length > 0 + - (genome_moteur_colis[0] | from_json).avant + != (genome_moteur_colis[0] | from_json).apres + # Le genome n'a pas a trainer en double sur la machine : ce qui compte est dans les # depots et sur la forge. - name: Retirer les colis