doc : la machine d'epreuve jetable — une doctrine qui n'avait pas son instrument
L'exploitant a decouvert par hasard, en creusant l'intrant « pont reseau », qu'on peut fabriquer une VM HORS DU PLAN. Verification : `cloner-vm` n'etait mentionne qu'UNE fois dans tout le depot, comme note de plomberie. L'usage n'etait nulle part. Or le depot porte deja la regle « eprouver l'outil avant d'ecrire le role qui l'enveloppe » — elle a evite les bugs de premier deploiement de rspamd et tranche le pivot Stalwart -> Postfix/Dovecot. L'instrument de cette regle n'etait pas nomme. DOCUMENTER LA DISCIPLINE, PAS SEULEMENT LA CAPACITE. Une telle VM est NUE : l'inventaire ne la contient pas, `make raser` ne la detruira JAMAIS (il derive du plan), aucun DNS, certificat, sauvegarde, pare-feu ni nftables, et son VMID n'est garde par aucune preuve. Elle ne disparait que si on la detruit soi-meme — un VMID oublie squatte le cluster sans que rien ne le signale, exactement comme un pont disparu a survecu dix jours dans une declaration ce matin. Ecrit pour trois lecteurs : le GESTE dans vm-lifecycle.md §4bis, la CAPACITE dans pouvoirs-set-ops.md (qui evalue le moteur), le REFLEXE dans la discipline de carte-set-ops.md (qui modifie le moteur). Decouvrir une capacite de son propre outil par accident est le signe qu'elle manquait a la documentation, pas au code. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
parent
e5bf7eb7b7
commit
eab4975ab1
4 changed files with 97 additions and 1 deletions
45
CHANGELOG.md
45
CHANGELOG.md
|
|
@ -1,5 +1,50 @@
|
|||
# CHANGELOG — Set-OPS
|
||||
|
||||
## 2026-08-13 — La machine d'épreuve jetable existait, et n'était écrite nulle part
|
||||
|
||||
L'exploitant a découvert par hasard, en creusant l'intrant « pont réseau », qu'on peut
|
||||
fabriquer une VM **hors du plan**. Vérification : `cloner-vm` n'était mentionné qu'**une
|
||||
fois** dans tout le dépôt, comme note de plomberie dans `dimensionnement-ressources.md`.
|
||||
L'usage, lui, n'était nulle part.
|
||||
|
||||
### Une doctrine sans son instrument
|
||||
|
||||
Le dépôt porte déjà la règle *« éprouver l'outil avant d'écrire le rôle qui l'enveloppe »* —
|
||||
elle a évité les bugs de premier déploiement de rspamd et tranché le pivot Stalwart →
|
||||
Postfix/Dovecot. Mais **l'instrument de cette règle n'était pas nommé**.
|
||||
|
||||
```
|
||||
make cloner-vm HOTE=essai-nginx VMID=99123 PONT_PROXMOX=t17appl \
|
||||
ADRESSE_IP=10.17.21.99 CIDR=24 PASSERELLE=10.17.21.1
|
||||
```
|
||||
|
||||
Une Debian issue du gabarit doré, sur le réseau choisi, en deux minutes, sans toucher au
|
||||
plan. C'est ainsi que `modeleSetOPS` a lui-même été recapturé.
|
||||
|
||||
### Documenter la discipline, pas seulement la capacité
|
||||
|
||||
Une telle VM est **nue** — et c'est à la fois l'intérêt et le danger :
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| l'inventaire | ne la contient pas |
|
||||
| **`make raser`** | ne la détruira **jamais** — il dérive du plan |
|
||||
| DNS, certificat, sauvegarde, pare-feu, nftables | aucun |
|
||||
| son VMID | gardé par aucune preuve contre une collision |
|
||||
|
||||
Elle ne disparaît que si on la détruit soi-même. Un VMID oublié squatte le cluster sans
|
||||
que rien ne le signale — c'est très exactement ainsi qu'un pont disparu a survécu dix jours
|
||||
dans une déclaration, le matin même.
|
||||
|
||||
Écrit à trois endroits, pour trois lecteurs : le **geste** dans `vm-lifecycle.md` §4bis, la
|
||||
**capacité** dans `pouvoirs-set-ops.md` (qui évalue le moteur), et le **réflexe** dans la
|
||||
discipline de `carte-set-ops.md` (qui modifie le moteur).
|
||||
|
||||
> **Le symptôme valait le diagnostic.** Découvrir une capacité de son propre outil par
|
||||
> accident, en creusant autre chose, est le signe qu'elle manquait à la documentation —
|
||||
> pas au code.
|
||||
|
||||
|
||||
## 2026-08-13 — Le « pont réseau » n'était pas un réglage, et l'intitulé le dit maintenant
|
||||
|
||||
Question de l'exploitant après la découverte de `vmbr3` : *à quoi sert l'intrant « pont
|
||||
|
|
|
|||
|
|
@ -94,6 +94,10 @@ Ce que je re-découvre sinon. **Consulter avant de concevoir un nouveau mécanis
|
|||
Avant de concevoir ou d'ajouter un mécanisme :
|
||||
1. lire **cette carte** + le doc du sujet ;
|
||||
2. **arpenter le code** (`grep`) et **lire les README des rôles** concernés ;
|
||||
3. **étendre / factoriser** l'existant plutôt qu'ajouter un chemin parallèle.
|
||||
3. **éprouver l'outil AVANT d'écrire le rôle** qui l'enveloppe — une machine jetable hors
|
||||
plan se fabrique en deux minutes (`make cloner-vm`, cf. `vm-lifecycle.md` §4bis). C'est
|
||||
ce qui a évité les bugs de premier déploiement de rspamd, et ce qui a tranché le pivot
|
||||
Stalwart → Postfix/Dovecot. Elle est invisible au moteur : **à détruire à la main** ;
|
||||
4. **étendre / factoriser** l'existant plutôt qu'ajouter un chemin parallèle.
|
||||
|
||||
Un seul agent IA travaille dans le dépôt à la fois (Codex **ou** Claude) — cf. `AGENTS.md`.
|
||||
|
|
|
|||
|
|
@ -110,6 +110,10 @@ prouvés.
|
|||
- **Méthode « éprouver l'outil avant le rôle »** — inspecter empiriquement le vrai binaire avant
|
||||
d'écrire le rôle qui l'enveloppe. A évité les bugs de premier déploiement (rspamd : zéro bug ;
|
||||
pivot Stalwart → Postfix/Dovecot/rspamd décidé sur preuve).
|
||||
- **Machine d'épreuve jetable** (`make cloner-vm`) — l'**instrument** de la méthode ci-dessus :
|
||||
une Debian issue du gabarit doré, sur le réseau choisi, en deux minutes, **hors du plan**. Le
|
||||
moteur ne la connaît pas — donc aucune politique, aucun certificat, aucune sauvegarde, et
|
||||
`make raser` ne la détruira jamais. À détruire à la main. Voir `vm-lifecycle.md` §4bis.
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -98,6 +98,49 @@ agrandissement disque
|
|||
|
||||
Cloud-init ne remplace pas Ansible pour la configuration réelle du serveur.
|
||||
|
||||
### 4bis. Une VM HORS PLAN, pour éprouver
|
||||
|
||||
`make creer-vm HOTE=idm-01` dérive **tout** de l'inventaire — VMID, IP, VLAN, pont,
|
||||
stockage. C'est la voie normale, celle qu'emprunte `flotte-creer`.
|
||||
|
||||
Sous elle vit une couche qui ne consulte **aucun plan** :
|
||||
|
||||
```
|
||||
make cloner-vm HOTE=essai-nginx VMID=99123 PONT_PROXMOX=t17appl \
|
||||
ADRESSE_IP=10.17.21.99 CIDR=24 PASSERELLE=10.17.21.1
|
||||
```
|
||||
|
||||
Une Debian issue du gabarit doré, sur le réseau que vous choisissez, en deux minutes.
|
||||
Elle n'apparaît nulle part dans le plan.
|
||||
|
||||
**À quoi ça sert.** À honorer une règle du dépôt : *éprouver l'outil avant d'écrire le
|
||||
rôle qui l'enveloppe.* Avant de mettre un binaire en boîte — vérifier ses options réelles,
|
||||
sa configuration, ce qu'il fait au premier démarrage — on veut une machine vraie, jetable,
|
||||
qui ne salit rien. C'est ce que fournit `cloner-vm`. Le gabarit `modeleSetOPS` a lui-même
|
||||
été recapturé ainsi.
|
||||
|
||||
> **Elle est NUE, et c'est à la fois l'intérêt et le danger.** Le moteur ne la connaît
|
||||
> pas :
|
||||
>
|
||||
> | | |
|
||||
> |---|---|
|
||||
> | l'inventaire | ne la contient pas |
|
||||
> | **`make raser`** | ne la détruira **jamais** — il dérive du plan |
|
||||
> | DNS, certificat, sauvegarde | aucun |
|
||||
> | pare-feu Proxmox, nftables | aucune politique |
|
||||
> | son VMID | gardé par aucune preuve contre une collision |
|
||||
>
|
||||
> Elle ne disparaît donc que si **vous** la détruisez :
|
||||
>
|
||||
> ```
|
||||
> ansible-playbook playbooks/proxmox/supprimer_vm_debian.yml -e vmid=99123
|
||||
> ```
|
||||
>
|
||||
> Choisissez un VMID **hors des plages dérivées** (les tenants occupent
|
||||
> `<VLAN><hôte><séq>`, neuf chiffres) et notez-le. Un VMID oublié squatte le cluster sans
|
||||
> que rien ne le signale — c'est exactement ainsi qu'un pont disparu a survécu dix jours
|
||||
> dans une déclaration, en août 2026.
|
||||
|
||||
## 5. Groupes opérationnels
|
||||
|
||||
Une VM déployée doit être placée dans les groupes d'inventaire qui décrivent l'état voulu.
|
||||
|
|
|
|||
Loading…
Reference in a new issue