reconstruction de confirmation : 0 echec, 34 minutes
Seconde reconstruction complete de Chezlepro dans la journee, pour
EPROUVER les quatre correctifs livres entre les deux. Rien de nouveau
n a ete construit : c est une mesure.
gabarit sur CephNVMe clonage 4 min 30 contre ~30 min
placement declare {asgard: 14} - les quatorze au bon endroit
hosts_statiques conditionne changed au 1er passage, skipping au 2e
monitoring-plugins au role ping4 14/14 OK sur une mon-01 nee neuve
Le troisieme est le plus instructif : les DEUX branches sont exercees dans
la meme execution. infra-pki-01 recoit le gabarit maitre de cloud-init au
premier passage, puis la tache est sautee au second, le durcissement
l ayant retire. Aucune preuve statique ne pouvait montrer cela - il fallait
une naissance.
Le facteur mesure est 6,6 et non 45 : un clone isole prend 8 s, mais quatre
clones se disputent le pool et le redimensionnement du disque s ajoute. On
retient la mesure en conditions reelles, celle qu on paie.
Des trois echecs du matin il ne reste rien. Le verrou dpkg ne s est pas
reproduit - c etait une course, et rien ne dit qu elle ne reviendra pas.
Et le cache apt N ETAIT PAS un defaut : les deux seuls fatal de cette
execution sont suivis de ...ignoring, ce sont les sondes de
client_artefacts qui laissent la machine servie par le plancher du SITE.
C est la filiation en train de fonctionner. Le matin, j avais compte ces
deux lignes comme des echecs sans lire la suivante.
Icinga : 89 OK, 9 UNKNOWN sur 98, aucun WARNING, aucun CRITICAL. Les neuf
sont tous des sauvegarde dont le minuteur nocturne n a pas encore visite
une flotte nee il y a vingt minutes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
This commit is contained in:
parent
2cf68c2d30
commit
9685e0bdbe
1 changed files with 54 additions and 0 deletions
54
CHANGELOG.md
54
CHANGELOG.md
|
|
@ -1,5 +1,59 @@
|
|||
# CHANGELOG — Set-OPS
|
||||
|
||||
## 2026-09-10 (9) — La reconstruction de confirmation : 0 echec, 34 minutes
|
||||
|
||||
Seconde reconstruction complete de Chezlepro dans la journee, cette fois pour EPROUVER les
|
||||
quatre correctifs livres entre les deux. Rien de nouveau n'a ete construit : c'est une
|
||||
mesure.
|
||||
|
||||
rc=0 0 echec 0 injoignable 14 / 14 machines
|
||||
34 min contre 68 le matin meme
|
||||
|
||||
### Les quatre points, et leur verdict
|
||||
|
||||
| ce qui etait a eprouver | verdict |
|
||||
|---|---|
|
||||
| gabarit sur `CephNVMe` | phase de clonage **4 min 30** contre ~30 min |
|
||||
| placement declare (`noeud: asgard`) | `{'asgard': 14}` — les quatorze au bon endroit |
|
||||
| `hosts_statiques` conditionne a cloud-init | `changed` au 1er passage, `skipping` au 2e |
|
||||
| `monitoring-plugins-basic` au role | `ping4` **14/14 OK** sur une `mon-01` nee neuve |
|
||||
|
||||
Le troisieme est le plus instructif : **les deux branches sont exercees dans la meme
|
||||
execution.** `infra-pki-01` recoit le gabarit maitre de cloud-init au premier passage
|
||||
(cloud-init est encore la), puis la tache est SAUTEE au second (le durcissement l'a
|
||||
retire). Aucune preuve statique ne pouvait montrer cela — il fallait une naissance.
|
||||
|
||||
### Le facteur 6,6, et pourquoi ce n'est pas 45
|
||||
|
||||
Un clone isole sur Ceph prend 8 s contre 352 a 480 s sur TrueNAS : facteur 45. En
|
||||
conditions reelles il tombe a **6,6** — quatre clones se disputent le meme pool, et le
|
||||
redimensionnement du disque s'ajoute a la copie. On retient la mesure en conditions
|
||||
reelles : celle qui compte est celle qu'on paie.
|
||||
|
||||
### Ce que les echecs du matin sont devenus
|
||||
|
||||
- **`/etc/cloud`** — corrige, prouve dans ses deux branches.
|
||||
- **Verrou `dpkg`** — ne s'est pas reproduit. C'etait une course, pas un defaut de
|
||||
structure ; rien ne dit qu'elle ne reviendra pas, et le dire vaut mieux que la declarer
|
||||
reglee.
|
||||
- **Cache apt** — **n'etait pas un defaut**. Les deux seuls `fatal:` de cette execution
|
||||
sont suivis de `...ignoring` : ce sont les sondes de `client_artefacts`, qui cherchent le
|
||||
cache du tenant, ne le trouvent pas, et laissent la machine servie par le plancher du
|
||||
SITE. C'est la filiation en train de fonctionner. Le matin, j'avais compte ces deux
|
||||
lignes comme des echecs sans lire la suivante.
|
||||
- **`auditd` sans regles dans le gabarit** — toujours la, mais invisible : aucune machine
|
||||
n'ayant decroche avant le socle, le CRITICAL transitoire a ete repare partout avant
|
||||
d'etre mesure. *Un defaut qui ne se voit que lorsqu'autre chose casse reste un defaut.*
|
||||
|
||||
### Etat mesure
|
||||
|
||||
Icinga 89 OK | 9 UNKNOWN sur 98 — aucun WARNING, aucun CRITICAL
|
||||
les 9 tous des `sauvegarde` : le minuteur nocturne n'a pas encore visite
|
||||
une flotte nee il y a vingt minutes
|
||||
|
||||
La condition posee avant de retirer les disques `unused0`/`unused1` du gabarit sur TrueNAS
|
||||
est **levee** : une flotte complete est nee du nouveau gabarit, sans un echec.
|
||||
|
||||
## 2026-09-10 (8) — Une garde qui survit a ce qu'elle gardait
|
||||
|
||||
Le defaut le plus couteux de la reconstruction, corrige. Il n'arretait rien de visible :
|
||||
|
|
|
|||
Loading…
Reference in a new issue