genome pousse : celui qui pousse avance son propre clone, et sa console l'ignore
Le correctif de serveur_ops a eu sa preuve en conditions reelles : clone passe de6367d85af9a20b0chez les deux locataires, tache en changed, consoles reparties a 15h33m33 et 15h38m02 contre 15h16, sondes a 0. En la donnant, il a montre le cas qu'il ne couvre pas. genome_pousser.yml fait avancer le clone du runner du SITE sans qu'aucun role ne passe : c'est lui qui pousse, donc il recoit d'abord. Quand serveur_ops passera, le clone sera deja a jour et la tache s'abstiendra a juste titre — l'hebergeur gardait le defaut corrige chez ses locataires. Le playbook nomme deja la transition dans son verdict ; il en tire maintenant la consequence et redemarre la console du site quand c'est le MOTEUR qui a bouge. Un plan pousse ne coupe pas les pages ouvertes, et l'unite systemd est verifiee avant de toucher au service. Valide : --syntax-check contre l'inventaire du site et celui d'un locataire, ansible-lint sur le playbook (profil production, 0 echec, 0 avertissement), condition de declenchement eprouvee sur quatre cas dont le mode check. Limite : le redemarrage de la console du site demande une poussee posterieure a ce commit, il n'est donc pas encore observe. Son disque portef9a20b0, sa console sert le code charge a 15h16. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
parent
f9a20b0870
commit
f95873915f
2 changed files with 87 additions and 3 deletions
54
CHANGELOG.md
54
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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in a new issue