arcodangeandClaude Opus 5
d4edf66ff5
Helm Charts / Detect changed charts (pull_request) Successful in 1m46s
Helm Charts / Library charts tool (pull_request) Skipped
Helm Charts / Application charts alloy (pull_request) Skipped
Helm Charts / Application charts chart (pull_request) Skipped
Helm Charts / Application charts crowdsec (pull_request) Skipped
Helm Charts / Application charts grafana (pull_request) Skipped
Helm Charts / Application charts hashicorp-vault (pull_request) Skipped
Helm Charts / Application charts loki (pull_request) Skipped
Helm Charts / Application charts minio (pull_request) Skipped
Helm Charts / Application charts pgbouncer (pull_request) Skipped
Helm Charts / Application charts pgcat (pull_request) Skipped
Helm Charts / Application charts redis (pull_request) Skipped
Helm Charts / Application charts prometheus (pull_request) Successful in 29s
Le 14/09 à 05:16Z, le volume `prometheus-server` (moteur sur pi1, une réplique sur pi2 saturé en mémoire) a vu ext4 abandonner son journal et remonter en lecture seule. Prometheus a échoué à écrire son WAL pendant 27 h, puis panique en boucle (« Unable to create mmap-ed active query log ») depuis que la sonde de vivacité l'a redémarré. Un redémarrage de conteneur ne démonte pas le volume. Affinité requise `NotIn [pi2]` et préférence forte pour pi3 : recréé sur un autre nœud, le volume est détaché puis rattaché, et ext4 rejoue son journal. Sur le même nœud, le pod neuf pourrait réutiliser le montage de staging mort. Refs arcodange-org/tools#49 Co-Authored-By: Claude Opus 5 <[email protected]>