Mesuré le 2026-09-02 depuis le Mac, sur le déploiement public et le homelab.
Le fait
sonde
code
https://s3.arcodange.fr/minio/health/live
200 — le processus tourne
https://s3.arcodange.fr/minio/health/cluster
503
https://s3.arcodange.fr/minio/health/cluster/read
503
https://s3.arcodange.lab/minio/health/cluster
503 — même cluster, l'autre porte
Un PUT sur une URL correctement présignée rend :
503 SlowDownWrite — Resource requested is unwritable
⚠ Et ce n'est pas seulement l'écriture : les objets déposés le 2026-07-31 sont eux aussi illisibles (503). Le seau ne rend plus rien.
⚠ Le piège de supervision, et il vaut au-delà de cet incident
/minio/health/live répond 200 pendant que /minio/health/cluster répond 503.
Une sonde branchée sur live — le réflexe naturel — dirait « tout va bien » sur un stockage qui n'accepte plus un octet et n'en rend plus un seul. Le processus est vivant ; le cluster ne l'est pas. Si la supervision existe, elle regarde probablement le mauvais point.
Ce que ça bloque
kadans ne peut plus rien stocker : l'import d'une vidéo traverse tout l'écran (26 s, inscription, choix du fichier, découpage, URL signée) puis meurt sur le dépôt. Le produit entier repose sur ce seau.
⚠ Ce n'est pas le CORS : bun run check:cors est vert (PUT/GET/DELETE autorisés depuis https://kadans.arcodange.fr, origine bidon refusée, ETag lisible). La requête part et arrive ; c'est le magasin qui refuse.
⚠ Depuis quand — et le harnais le disait déjà
kadans a un parcours contre le déploiement (bun run test:parcours:homelab). Relevé le même jour : 3 rouges sur 11, dont littéralement « le magasin a refusé la part … 503 ».
L'instrument criait ; personne ne le lisait. Un harnais qu'aucune CI ne déclenche et que personne ne joue à la main finit par ne plus rien garder — cinquième variante de « un gate incapable d'échouer », par abandon plutôt que par écriture.
Pistes (non vérifiées — je n'ai pas accès au cluster)
SlowDownWrite + cluster 503 pointent typiquement vers un quorum de disques perdu ou un espace saturé. À confirmer sur place : mc admin info, l'état des drives, et l'espace disponible.
Ce qu'il faudrait ensuite, une fois réparé
Rejouer PARCOURS_CIBLE=public bun run test:import-reel (PR kadans#880) : il fait le chemin complet, de l'écran jusqu'à la relecture de l'objet, et compare l'image — pas les octets, le front ré-encode.
Brancher une sonde sur /minio/health/cluster, pas sur /live.
Mesuré le 2026-09-02 depuis le Mac, sur le déploiement public **et** le homelab.
## Le fait
| sonde | code |
|---|---|
| `https://s3.arcodange.fr/minio/health/live` | **200** — le processus tourne |
| `https://s3.arcodange.fr/minio/health/cluster` | **503** |
| `https://s3.arcodange.fr/minio/health/cluster/read` | **503** |
| `https://s3.arcodange.lab/minio/health/cluster` | **503** — même cluster, l'autre porte |
Un `PUT` sur une URL correctement présignée rend :
```
503 SlowDownWrite — Resource requested is unwritable
```
⚠ **Et ce n'est pas seulement l'écriture** : les objets déposés le **2026-07-31** sont eux aussi illisibles (503). Le seau ne rend plus rien.
## ⚠ Le piège de supervision, et il vaut au-delà de cet incident
**`/minio/health/live` répond 200 pendant que `/minio/health/cluster` répond 503.**
Une sonde branchée sur `live` — le réflexe naturel — dirait « tout va bien » sur un stockage qui n'accepte plus un octet et n'en rend plus un seul. **Le processus est vivant ; le cluster ne l'est pas.** Si la supervision existe, elle regarde probablement le mauvais point.
## Ce que ça bloque
`kadans` ne peut **plus rien stocker** : l'import d'une vidéo traverse tout l'écran (26 s, inscription, choix du fichier, découpage, URL signée) puis meurt sur le dépôt. Le produit entier repose sur ce seau.
⚠ Ce n'est **pas** le CORS : `bun run check:cors` est vert (PUT/GET/DELETE autorisés depuis `https://kadans.arcodange.fr`, origine bidon refusée, ETag lisible). La requête part et arrive ; c'est le magasin qui refuse.
## ⚠ Depuis quand — et le harnais le disait déjà
`kadans` a un parcours contre le déploiement (`bun run test:parcours:homelab`). Relevé le même jour : **3 rouges sur 11**, dont littéralement *« le magasin a refusé la part … 503 »*.
> **L'instrument criait ; personne ne le lisait.** Un harnais qu'aucune CI ne déclenche et que personne ne joue à la main finit par ne plus rien garder — cinquième variante de « un gate incapable d'échouer », par abandon plutôt que par écriture.
## Pistes (non vérifiées — je n'ai pas accès au cluster)
`SlowDownWrite` + `cluster` 503 pointent typiquement vers un **quorum de disques perdu** ou un **espace saturé**. À confirmer sur place : `mc admin info`, l'état des drives, et l'espace disponible.
## Ce qu'il faudrait ensuite, une fois réparé
- **Rejouer `PARCOURS_CIBLE=public bun run test:import-reel`** (PR `kadans#880`) : il fait le chemin complet, de l'écran jusqu'à la **relecture de l'objet**, et compare l'image — pas les octets, le front ré-encode.
- **Brancher une sonde sur `/minio/health/cluster`**, pas sur `/live`.
⚠ Correction : les pistes que j'avais données étaient fausses, et la panne est réparée
J'avais écrit « un quorum de disques perdu ou un espace saturé ». Mesuré : rien n'était plein.
ce que j'avais avancé
ce que la mesure a dit
espace saturé
df dans le pod : 42 G libres (16 %) ; Longhorn : pi1 151 Go, pi2 265 Go, pi3 112 Go disponibles
quorum de disques perdu
l'engine déclarait les trois répliques RW, volume attached/healthy, FilesystemReadOnly: False
(au passage) « le support physique est défectueux »
sdh est un VIRTUAL-DISK — c'est le volume Longhorn lui-même en iSCSI, pas un disque. Le vrai disque de pi2 (sda, 458 G) est à 49 % et sans erreur
La vraie chaîne, datée par le journal du noyau et celui du moteur
2026-08-29T14:11:27 R/W Timeout. No response received in 8s
2026-08-29T14:11:27 Backend tcp://10.42.1.183:10118 monitoring failed, mark as ERR
2026-08-29T15:26:49 Failed to read: index 1, off 27951202304 — connection reset by peer
2026-08-29T15:32:17 /dev/longhorn/pvc-ebb2605f…: Can't open blockdev
2026-08-29T17:54:06 EXT4-fs error (device sdh): comm minio: Detected aborted journal
Les répliques se sont perdues de vue sur le réseau, le moteur les a marquées ERR une à une, le périphérique bloc a disparu sous MinIO — et à 17 h 54 ext4 a abandonné son journal. À partir de là, toute écriture rend EIO.
⚠⚠ Le point qui explique pourquoi personne ne l'a vu pendant trois jours
Longhorn s'est rétabli tout seul le 30 août à 11 h 50. C'est pourquoi il affichait healthy — sincèrement, et il avait raison sur sa propre couche.
Mais un journal ext4 abandonné ne se répare jamais tout seul : il le reste jusqu'au démontage. MinIO est donc resté assis sur un montage mort deux jours après que le stockage sous-jacent soit réparé, pendant que Longhorn, les répliques, les nœuds et le pod (Running 1/1, 0 restart) affichaient tous vert.
Le pod ne redémarre pas quand son système de fichiers meurt. Le seul relevé qui tranchait était un touch dans le volume, et aucune sonde ne le faisait — ni la liveness de MinIO, ni Longhorn, ni Kubernetes.
Le remède appliqué
kubectl -n tools scale deploy/minio --replicas=0 → ArgoCD a remonté le pod → montage neuf.
avant
après
touch /export/…
Input/output error
ÉCRITURE OK / SUPPRESSION OK
« insufficient » dans le journal
6126
0
drives-online
0
nominal
Aucune donnée perdue : le bucket kadans-videos a ses 9 comptes et ses travail.mp4 / travail.webm / vignette.webp.
Et le parcours de bout en bout — GUI de kadans.arcodange.fr → import → octets dans le seau → la vidéo revient à la galerie — passe : 1 passed, code de sortie 0, contre la porte publique.
⚠ Ce qui reste ouvert, et qui n'est pas réglé
La cause première n'est pas traitée. Le déclencheur est un R/W Timeout de 8 s entre répliques — un problème de réseau ou de latence entre les pi, pas de disque. sdb (1 G, VIRTUAL-DISK lui aussi) avait rendu 10critical medium error le 15 août : c'est un motif qui se répète, pas un accident. Tant qu'il n'est pas compris, ça recommencera.
Il manque une sonde qui mesure l'écriture. Une liveness probe qui écrit puis efface un fichier témoin dans /export aurait fait redémarrer le pod en une minute au lieu de trois jours. C'est le correctif qui a le meilleur rapport valeur/coût ici.
⚠ Les sondes de engine-image et instance-manager sur pi2 expirent après 4 s sur un simple ls / cat — engine-image-ei-b4bcf0a5-h9664 porte 142 redémarrages. Symptôme probablement lié au point 1.
pi3 était Schedulable: False dans Longhorn au moment du relevé.
## ⚠ Correction : les pistes que j'avais données étaient fausses, et la panne est réparée
J'avais écrit « un quorum de disques perdu ou **un espace saturé** ». **Mesuré : rien n'était plein.**
| ce que j'avais avancé | ce que la mesure a dit |
|---|---|
| espace saturé | `df` dans le pod : **42 G libres (16 %)** ; Longhorn : pi1 **151 Go**, pi2 **265 Go**, pi3 **112 Go** disponibles |
| quorum de disques perdu | l'`engine` déclarait les **trois** répliques `RW`, volume `attached`/`healthy`, `FilesystemReadOnly: False` |
| (au passage) « le support physique est défectueux » | `sdh` est un `VIRTUAL-DISK` — **c'est le volume Longhorn lui-même** en iSCSI, pas un disque. Le vrai disque de pi2 (`sda`, 458 G) est à 49 % et sans erreur |
### La vraie chaîne, datée par le journal du noyau et celui du moteur
```
2026-08-29T14:11:27 R/W Timeout. No response received in 8s
2026-08-29T14:11:27 Backend tcp://10.42.1.183:10118 monitoring failed, mark as ERR
2026-08-29T15:26:49 Failed to read: index 1, off 27951202304 — connection reset by peer
2026-08-29T15:32:17 /dev/longhorn/pvc-ebb2605f…: Can't open blockdev
2026-08-29T17:54:06 EXT4-fs error (device sdh): comm minio: Detected aborted journal
```
Les répliques se sont perdues de vue sur le réseau, le moteur les a marquées `ERR` une à une, le périphérique bloc a disparu sous MinIO — et à 17 h 54 **ext4 a abandonné son journal**. À partir de là, toute écriture rend `EIO`.
### ⚠⚠ Le point qui explique pourquoi personne ne l'a vu pendant trois jours
**Longhorn s'est rétabli tout seul le 30 août à 11 h 50.** C'est pourquoi il affichait `healthy` — sincèrement, et il avait raison sur sa propre couche.
Mais **un journal ext4 abandonné ne se répare jamais tout seul** : il le reste jusqu'au démontage. MinIO est donc resté assis sur un montage mort **deux jours après que le stockage sous-jacent soit réparé**, pendant que Longhorn, les répliques, les nœuds et le pod (`Running 1/1`, `0 restart`) affichaient tous vert.
> **Le pod ne redémarre pas quand son système de fichiers meurt.** Le seul relevé qui tranchait était un `touch` dans le volume, et aucune sonde ne le faisait — ni la *liveness* de MinIO, ni Longhorn, ni Kubernetes.
### Le remède appliqué
`kubectl -n tools scale deploy/minio --replicas=0` → ArgoCD a remonté le pod → **montage neuf**.
| | avant | après |
|---|---|---|
| `touch /export/…` | `Input/output error` | **ÉCRITURE OK** / **SUPPRESSION OK** |
| « insufficient » dans le journal | **6126** | **0** |
| `drives-online` | **0** | nominal |
**Aucune donnée perdue** : le bucket `kadans-videos` a ses 9 comptes et ses `travail.mp4` / `travail.webm` / `vignette.webp`.
Et le parcours de bout en bout — GUI de `kadans.arcodange.fr` → import → **octets dans le seau** → la vidéo revient à la galerie — passe : `1 passed`, code de sortie 0, contre la porte **publique**.
### ⚠ Ce qui reste ouvert, et qui n'est pas réglé
1. **La cause première n'est pas traitée.** Le déclencheur est un `R/W Timeout` de 8 s entre répliques — un problème de **réseau ou de latence entre les pi**, pas de disque. `sdb` (1 G, `VIRTUAL-DISK` lui aussi) avait rendu **10** `critical medium error` le 15 août : **c'est un motif qui se répète**, pas un accident. Tant qu'il n'est pas compris, ça recommencera.
2. **Il manque une sonde qui mesure l'écriture.** Une *liveness probe* qui écrit puis efface un fichier témoin dans `/export` aurait fait redémarrer le pod en une minute au lieu de trois jours. C'est le correctif qui a le meilleur rapport valeur/coût ici.
3. ⚠ Les sondes de `engine-image` et `instance-manager` sur pi2 **expirent après 4 s** sur un simple `ls` / `cat` — `engine-image-ei-b4bcf0a5-h9664` porte **142 redémarrages**. Symptôme probablement lié au point 1.
4. **pi3 était `Schedulable: False`** dans Longhorn au moment du relevé.
✅ La moitié « observabilité » est livrée et déployée — #32 mergée
MinIO porte enfin des sondes. Constaté sur le déploiement, pas déduit :
startupProbe /minio/health/live:9000 période 5s × seuil 24 = 120 s
readinessProbe /minio/health/cluster:9000 période 15s × seuil 3 = 45 s
livenessProbe /minio/health/cluster:9000 période 30s × seuil 6 = 180 s
stratégie : Recreate
ArgoCD Synced / Healthy, pod 1/1 Running, 0 redémarrage, écriture et suppression OK, bucket intact. Et le parcours de bout en bout — GUI kadans.arcodange.fr → import → octets dans le seau → retour galerie — repasse contre le déploiement neuf : 1 passed, code 0.
⚠ /minio/health/live ne suffisait pas, et c'est mesuré : il répond 200 sur un magasin qui ne peut plus écrire. C'est cluster qui voit le quorum.
⚠⚠ Un second défaut trouvé en chemin, et il dépasse MinIO
La CI de ce dépôt ne construisait que 2 charts sur 10.
Trouvé en refusant de lire le vert de #32 : elle réécrivait le chart minio en entier, et la CI rendait success avec Detect changed charts ✓ et les deux jobs de construction Skipped. Aucun job Application charts minio n'existait.
La cause : Gitea ne sait pas monter une matrice dynamique, donc chart: [tool] et chart: [pgcat] sont codés en dur. Le job filter-chart calcule pourtant la bonne réponse — et personne ne la consomme : le if: vérifie seulement si le chart codé en dur figure dans la liste détectée.
minio, redis, crowdsec, hashicorp-vault, grafana, prometheus, pgbouncer et chart ne passaient donc sous aucun helm template, et toute PR qui les touchait affichait vert.
Le remède ne demande pas de matrice dynamique : le if: filtre déjà sur la sortie du détecteur, donc un chart non modifié reste Skipped. Il ne manquait que l'énumération. Mesuré après correction, sur la même PR :
avant
après
contextes de CI
3
11
Application charts minio
n'existait pas
success, construit pour de vrai
charts non modifiés
—
skipped
⚠ Le mode d'échec est maintenant écrit dans le fichier : ajouter un chart au dépôt sans l'ajouter à la liste le rend invisible à la CI, en silence.
Ce qui reste ouvert dans cette issue
Ce lot rend la prochaine occurrence visible et auto-réparée en 3 minutes. Il ne l'empêche pas. Restent :
La cause première — le timeout réseau entre répliques Longhorn. sdb avait rendu 10 critical medium error identiques le 15 août : c'est un motif, pas un accident.
Les sondes Longhorn qui expirent sur pi2 — ls /data/longhorn et cat /var/run/ganesha.pid au-delà de 4 s ; engine-image-ei-b4bcf0a5-h9664 porte 142 redémarrages.
pi3 Schedulable: False au moment du relevé.
La leçon qui vaut au-delà de MinIO : un instrument qui déclare « sain » sur sa PROPRE couche ne dit rien de la couche au-dessus. Longhorn avait raison sur ses répliques, ArgoCD sur son manifeste, la CI sur les jobs qu'elle avait lancés. Les trois mentaient sur ce qui comptait. Le seul relevé qui tranchait était un touch dans le volume — et personne ne le faisait.
## ✅ La moitié « observabilité » est livrée et déployée — #32 mergée
MinIO porte enfin des sondes. Constaté sur le déploiement, pas déduit :
```
startupProbe /minio/health/live:9000 période 5s × seuil 24 = 120 s
readinessProbe /minio/health/cluster:9000 période 15s × seuil 3 = 45 s
livenessProbe /minio/health/cluster:9000 période 30s × seuil 6 = 180 s
stratégie : Recreate
```
ArgoCD `Synced / Healthy`, pod `1/1 Running`, **0 redémarrage**, écriture et suppression OK, bucket intact. Et le parcours de bout en bout — GUI `kadans.arcodange.fr` → import → **octets dans le seau** → retour galerie — repasse contre le déploiement neuf : `1 passed`, code 0.
⚠ **`/minio/health/live` ne suffisait pas, et c'est mesuré** : il répond 200 sur un magasin qui ne peut plus écrire. C'est `cluster` qui voit le quorum.
## ⚠⚠ Un second défaut trouvé en chemin, et il dépasse MinIO
**La CI de ce dépôt ne construisait que 2 charts sur 10.**
Trouvé en refusant de lire le vert de #32 : elle réécrivait le chart `minio` en entier, et la CI rendait `success` avec `Detect changed charts` ✓ et les deux jobs de construction **`Skipped`**. Aucun job `Application charts minio` n'existait.
La cause : Gitea ne sait pas monter une matrice **dynamique**, donc `chart: [tool]` et `chart: [pgcat]` sont codés en dur. Le job `filter-chart` calcule **pourtant la bonne réponse** — et personne ne la consomme : le `if:` vérifie seulement si le chart codé en dur figure dans la liste détectée.
`minio`, `redis`, `crowdsec`, `hashicorp-vault`, `grafana`, `prometheus`, `pgbouncer` et `chart` ne passaient donc **sous aucun `helm template`**, et toute PR qui les touchait affichait vert.
Le remède ne demande pas de matrice dynamique : le `if:` filtre déjà sur la sortie du détecteur, donc un chart non modifié reste `Skipped`. **Il ne manquait que l'énumération.** Mesuré après correction, sur la même PR :
| | avant | après |
|---|---|---|
| contextes de CI | **3** | **11** |
| `Application charts minio` | **n'existait pas** | **`success`, construit pour de vrai** |
| charts non modifiés | — | `skipped` |
⚠ Le mode d'échec est maintenant écrit dans le fichier : **ajouter un chart au dépôt sans l'ajouter à la liste le rend invisible à la CI, en silence.**
## Ce qui reste ouvert dans cette issue
Ce lot rend la prochaine occurrence **visible et auto-réparée en 3 minutes**. Il ne l'empêche pas. Restent :
1. **La cause première** — le timeout réseau entre répliques Longhorn. `sdb` avait rendu 10 `critical medium error` identiques le 15 août : c'est un motif, pas un accident.
2. **Les sondes Longhorn qui expirent sur pi2** — `ls /data/longhorn` et `cat /var/run/ganesha.pid` au-delà de 4 s ; `engine-image-ei-b4bcf0a5-h9664` porte 142 redémarrages.
3. **pi3 `Schedulable: False`** au moment du relevé.
> La leçon qui vaut au-delà de MinIO : **un instrument qui déclare « sain » sur sa PROPRE couche ne dit rien de la couche au-dessus.** Longhorn avait raison sur ses répliques, ArgoCD sur son manifeste, la CI sur les jobs qu'elle avait lancés. Les trois mentaient sur ce qui comptait. Le seul relevé qui tranchait était un `touch` dans le volume — et personne ne le faisait.
Résilience : ce que la mesure permet, et ce qu'elle interdit
Direction du fondateur (2026-09-02) : « sortir de Longhorn est une possibilité. Ce serait bien d'avoir une solution résiliente tout de même. » Je n'exécute rien ici — je pose les chiffres et les options, l'arbitrage reste ouvert.
⚠ Un fait qui a changé de statut
Le Chart.yaml justifiait le mode standalone par : « la donnée servie ici est DÉRIVÉE — le master d'une vidéo reste sur l'appareil de son propriétaire ». C'était vrai. Mais le produit promet désormais une sauvegarde automatique dès qu'un compte est ouvert : le bucket est la copie de secours de l'utilisateur.
Une sauvegarde qu'on peut perdre n'est pas une sauvegarde. La résilience est passée de confort technique à promesse produit.
Ce que la grappe peut porter, mesuré
RAM libre
sda (USB, 465 Go)
carte SD
pi1
1 Go / 7
118 Go libres (73 %)
119 Go
pi2
1 Go / 7
224 Go libres (49 %)
119 Go
pi3
3 Go / 7
82 Go libres (82 %)
59,5 Go
⚠ MinIO distribué en erasure coding est HORS DE PORTÉE : deux nœuds sur trois n'ont plus qu'un giga libre. Le Chart.yaml avait raison sur ce point, et cette raison-là n'a pas bougé.
⚠ Et les trois sda sont des disques Generic en USB, sur la même étagère, très probablement sur la même alimentation. Trois répliques là-dessus sont des pannes CORRÉLÉES : un incident électrique ou un concentrateur USB emporte les trois d'un coup. Ce n'est pas la résilience qu'on croit acheter — et c'est exactement le genre de couplage que ce ticket vient de démontrer sur le réseau.
⚠⚠ Sortir MinIO de Longhorn ne répare RIEN pour les autres
15 volumes vivent sur Longhorn : erp (50 Gi), erp-sandbox (50 Gi), Vault (2 × 10 Gi), ClickHouse (16 Gi), Prometheus (8 Gi), Redis, CrowdSec, Traefik, url-shortener, prospection, backups-rwx… MinIO n'en est qu'un. La cause première resterait entière pour les quatorze autres, et ils n'ont, eux, aucune sonde qui les réveillerait.
C'est le point décisif : le sujet n'est pas « où mettre MinIO », c'est « Longhorn tient-il sur cette grappe ».
Les options, avec leur prix
ce que ça donne
ce que ça coûte
A — rester sur Longhorn, comprendre les timeouts
répare les 15 volumes d'un coup
du temps de diagnostic, sans garantie d'aboutir
B — MinIO en local-path + réplication de bucket vers un second MinIO sur pi3
survit à la mort d'un nœud, sans Longhorn, sans erasure coding
~512 Mi de RAM sur pi3 (il en a 3 Go) · ⚠ pi3 n'a que 82 Go libres · ne résout rien pour les 14 autres · ⚠ pannes toujours corrélées (même étagère)
C — MinIO en local-path + réplication vers Cloudflare R2
résilience hors site — survit à ce qui emporte les trois pi
~0 RAM · ~0,11 $/mois aux 7,6 Go actuels · ⚠ les vidéos sortent du homelab, ce qui touche la promesse produit sur le lieu de la donnée · ADR-012 prévoit déjà R2
D — Longhorn à 2 répliques + réglages
moins de trafic entre nœuds, donc moins de timeouts
⚠ moins de redondance, et on garde la cause
Ce que je recommanderais, et pourquoi
A d'abord, pas B ni C. Parce que le problème mesuré n'est pas « MinIO est mal placé » — c'est « quinze volumes reposent sur une couche qui perd ses répliques sur le réseau, et un seul d'entre eux a une sonde ». Déplacer MinIO réglerait le cas qui nous a fait mal et laisserait Vault, ClickHouse et l'ERP exactement où ils sont.
Et C mérite d'exister de toute façon, mais comme sauvegarde hors site, pas comme remplacement : trois répliques sur trois disques USB de la même étagère ne protègent contre aucun sinistre qui touche l'étagère. ⚠ Sa seule vraie question est produit, pas technique : la promesse faite à l'utilisateur sur où vit son travail (app/lib/ou-vit-ton-travail.ts côté front).
Décision au fondateur. Rien n'est engagé.
## Résilience : ce que la mesure permet, et ce qu'elle interdit
Direction du fondateur (2026-09-02) : *« sortir de Longhorn est une possibilité. Ce serait bien d'avoir une solution résiliente tout de même. »* Je n'exécute rien ici — je pose les chiffres et les options, l'arbitrage reste ouvert.
### ⚠ Un fait qui a changé de statut
Le `Chart.yaml` justifiait le mode standalone par : *« la donnée servie ici est DÉRIVÉE — le master d'une vidéo reste sur l'appareil de son propriétaire »*. C'était vrai. Mais **le produit promet désormais une sauvegarde automatique dès qu'un compte est ouvert** : le bucket **est** la copie de secours de l'utilisateur.
> **Une sauvegarde qu'on peut perdre n'est pas une sauvegarde.** La résilience est passée de confort technique à **promesse produit**.
### Ce que la grappe peut porter, mesuré
| | RAM libre | `sda` (USB, 465 Go) | carte SD |
|---|---|---|---|
| pi1 | **1 Go / 7** | 118 Go libres (73 %) | 119 Go |
| pi2 | **1 Go / 7** | 224 Go libres (49 %) | 119 Go |
| pi3 | 3 Go / 7 | **82 Go libres (82 %)** | 59,5 Go |
⚠ **MinIO distribué en erasure coding est HORS DE PORTÉE** : deux nœuds sur trois n'ont plus qu'un giga libre. Le `Chart.yaml` avait raison sur ce point, et cette raison-là n'a pas bougé.
⚠ Et les trois `sda` sont des disques **`Generic` en USB**, sur la même étagère, très probablement sur la même alimentation. **Trois répliques là-dessus sont des pannes CORRÉLÉES** : un incident électrique ou un concentrateur USB emporte les trois d'un coup. Ce n'est pas la résilience qu'on croit acheter — et c'est exactement le genre de couplage que ce ticket vient de démontrer sur le réseau.
### ⚠⚠ Sortir MinIO de Longhorn ne répare RIEN pour les autres
**15 volumes vivent sur Longhorn** : `erp` (50 Gi), `erp-sandbox` (50 Gi), Vault (2 × 10 Gi), ClickHouse (16 Gi), Prometheus (8 Gi), Redis, CrowdSec, Traefik, `url-shortener`, `prospection`, `backups-rwx`… MinIO n'en est qu'un. **La cause première resterait entière pour les quatorze autres**, et ils n'ont, eux, aucune sonde qui les réveillerait.
C'est le point décisif : le sujet n'est pas « où mettre MinIO », c'est **« Longhorn tient-il sur cette grappe »**.
### Les options, avec leur prix
| | ce que ça donne | ce que ça coûte |
|---|---|---|
| **A — rester sur Longhorn, comprendre les timeouts** | répare les 15 volumes d'un coup | du temps de diagnostic, sans garantie d'aboutir |
| **B — MinIO en `local-path` + réplication de bucket vers un second MinIO sur pi3** | survit à la mort d'un nœud, sans Longhorn, sans erasure coding | ~512 Mi de RAM sur pi3 (il en a 3 Go) · ⚠ pi3 n'a que 82 Go libres · ne résout rien pour les 14 autres · ⚠ pannes toujours corrélées (même étagère) |
| **C — MinIO en `local-path` + réplication vers Cloudflare R2** | résilience **hors site** — survit à ce qui emporte les trois pi | ~0 RAM · ~0,11 $/mois aux 7,6 Go actuels · ⚠ **les vidéos sortent du homelab**, ce qui touche la promesse produit sur le lieu de la donnée · ADR-012 prévoit déjà R2 |
| **D — Longhorn à 2 répliques + réglages** | moins de trafic entre nœuds, donc moins de timeouts | ⚠ moins de redondance, et on garde la cause |
### Ce que je recommanderais, et pourquoi
**A d'abord, pas B ni C.** Parce que le problème mesuré n'est pas « MinIO est mal placé » — c'est **« quinze volumes reposent sur une couche qui perd ses répliques sur le réseau, et un seul d'entre eux a une sonde »**. Déplacer MinIO réglerait le cas qui nous a fait mal et laisserait Vault, ClickHouse et l'ERP exactement où ils sont.
Et **C mérite d'exister de toute façon**, mais comme *sauvegarde hors site*, pas comme remplacement : trois répliques sur trois disques USB de la même étagère ne protègent contre aucun sinistre qui touche l'étagère. ⚠ Sa seule vraie question est produit, pas technique : la promesse faite à l'utilisateur sur **où vit son travail** (`app/lib/ou-vit-ton-travail.ts` côté front).
**Décision au fondateur.** Rien n'est engagé.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Mesuré le 2026-09-02 depuis le Mac, sur le déploiement public et le homelab.
Le fait
https://s3.arcodange.fr/minio/health/livehttps://s3.arcodange.fr/minio/health/clusterhttps://s3.arcodange.fr/minio/health/cluster/readhttps://s3.arcodange.lab/minio/health/clusterUn
PUTsur une URL correctement présignée rend :⚠ Et ce n'est pas seulement l'écriture : les objets déposés le 2026-07-31 sont eux aussi illisibles (503). Le seau ne rend plus rien.
⚠ Le piège de supervision, et il vaut au-delà de cet incident
/minio/health/liverépond 200 pendant que/minio/health/clusterrépond 503.Une sonde branchée sur
live— le réflexe naturel — dirait « tout va bien » sur un stockage qui n'accepte plus un octet et n'en rend plus un seul. Le processus est vivant ; le cluster ne l'est pas. Si la supervision existe, elle regarde probablement le mauvais point.Ce que ça bloque
kadansne peut plus rien stocker : l'import d'une vidéo traverse tout l'écran (26 s, inscription, choix du fichier, découpage, URL signée) puis meurt sur le dépôt. Le produit entier repose sur ce seau.⚠ Ce n'est pas le CORS :
bun run check:corsest vert (PUT/GET/DELETE autorisés depuishttps://kadans.arcodange.fr, origine bidon refusée, ETag lisible). La requête part et arrive ; c'est le magasin qui refuse.⚠ Depuis quand — et le harnais le disait déjà
kadansa un parcours contre le déploiement (bun run test:parcours:homelab). Relevé le même jour : 3 rouges sur 11, dont littéralement « le magasin a refusé la part … 503 ».Pistes (non vérifiées — je n'ai pas accès au cluster)
SlowDownWrite+cluster503 pointent typiquement vers un quorum de disques perdu ou un espace saturé. À confirmer sur place :mc admin info, l'état des drives, et l'espace disponible.Ce qu'il faudrait ensuite, une fois réparé
PARCOURS_CIBLE=public bun run test:import-reel(PRkadans#880) : il fait le chemin complet, de l'écran jusqu'à la relecture de l'objet, et compare l'image — pas les octets, le front ré-encode./minio/health/cluster, pas sur/live.⚠ Correction : les pistes que j'avais données étaient fausses, et la panne est réparée
J'avais écrit « un quorum de disques perdu ou un espace saturé ». Mesuré : rien n'était plein.
dfdans le pod : 42 G libres (16 %) ; Longhorn : pi1 151 Go, pi2 265 Go, pi3 112 Go disponiblesenginedéclarait les trois répliquesRW, volumeattached/healthy,FilesystemReadOnly: Falsesdhest unVIRTUAL-DISK— c'est le volume Longhorn lui-même en iSCSI, pas un disque. Le vrai disque de pi2 (sda, 458 G) est à 49 % et sans erreurLa vraie chaîne, datée par le journal du noyau et celui du moteur
Les répliques se sont perdues de vue sur le réseau, le moteur les a marquées
ERRune à une, le périphérique bloc a disparu sous MinIO — et à 17 h 54 ext4 a abandonné son journal. À partir de là, toute écriture rendEIO.⚠⚠ Le point qui explique pourquoi personne ne l'a vu pendant trois jours
Longhorn s'est rétabli tout seul le 30 août à 11 h 50. C'est pourquoi il affichait
healthy— sincèrement, et il avait raison sur sa propre couche.Mais un journal ext4 abandonné ne se répare jamais tout seul : il le reste jusqu'au démontage. MinIO est donc resté assis sur un montage mort deux jours après que le stockage sous-jacent soit réparé, pendant que Longhorn, les répliques, les nœuds et le pod (
Running 1/1,0 restart) affichaient tous vert.Le remède appliqué
kubectl -n tools scale deploy/minio --replicas=0→ ArgoCD a remonté le pod → montage neuf.touch /export/…Input/output errordrives-onlineAucune donnée perdue : le bucket
kadans-videosa ses 9 comptes et sestravail.mp4/travail.webm/vignette.webp.Et le parcours de bout en bout — GUI de
kadans.arcodange.fr→ import → octets dans le seau → la vidéo revient à la galerie — passe :1 passed, code de sortie 0, contre la porte publique.⚠ Ce qui reste ouvert, et qui n'est pas réglé
R/W Timeoutde 8 s entre répliques — un problème de réseau ou de latence entre les pi, pas de disque.sdb(1 G,VIRTUAL-DISKlui aussi) avait rendu 10critical medium errorle 15 août : c'est un motif qui se répète, pas un accident. Tant qu'il n'est pas compris, ça recommencera./exportaurait fait redémarrer le pod en une minute au lieu de trois jours. C'est le correctif qui a le meilleur rapport valeur/coût ici.engine-imageetinstance-managersur pi2 expirent après 4 s sur un simplels/cat—engine-image-ei-b4bcf0a5-h9664porte 142 redémarrages. Symptôme probablement lié au point 1.Schedulable: Falsedans Longhorn au moment du relevé.✅ La moitié « observabilité » est livrée et déployée — #32 mergée
MinIO porte enfin des sondes. Constaté sur le déploiement, pas déduit :
ArgoCD
Synced / Healthy, pod1/1 Running, 0 redémarrage, écriture et suppression OK, bucket intact. Et le parcours de bout en bout — GUIkadans.arcodange.fr→ import → octets dans le seau → retour galerie — repasse contre le déploiement neuf :1 passed, code 0.⚠
/minio/health/livene suffisait pas, et c'est mesuré : il répond 200 sur un magasin qui ne peut plus écrire. C'estclusterqui voit le quorum.⚠⚠ Un second défaut trouvé en chemin, et il dépasse MinIO
La CI de ce dépôt ne construisait que 2 charts sur 10.
Trouvé en refusant de lire le vert de #32 : elle réécrivait le chart
minioen entier, et la CI rendaitsuccessavecDetect changed charts✓ et les deux jobs de constructionSkipped. Aucun jobApplication charts minion'existait.La cause : Gitea ne sait pas monter une matrice dynamique, donc
chart: [tool]etchart: [pgcat]sont codés en dur. Le jobfilter-chartcalcule pourtant la bonne réponse — et personne ne la consomme : leif:vérifie seulement si le chart codé en dur figure dans la liste détectée.minio,redis,crowdsec,hashicorp-vault,grafana,prometheus,pgbounceretchartne passaient donc sous aucunhelm template, et toute PR qui les touchait affichait vert.Le remède ne demande pas de matrice dynamique : le
if:filtre déjà sur la sortie du détecteur, donc un chart non modifié resteSkipped. Il ne manquait que l'énumération. Mesuré après correction, sur la même PR :Application charts miniosuccess, construit pour de vraiskipped⚠ Le mode d'échec est maintenant écrit dans le fichier : ajouter un chart au dépôt sans l'ajouter à la liste le rend invisible à la CI, en silence.
Ce qui reste ouvert dans cette issue
Ce lot rend la prochaine occurrence visible et auto-réparée en 3 minutes. Il ne l'empêche pas. Restent :
sdbavait rendu 10critical medium erroridentiques le 15 août : c'est un motif, pas un accident.ls /data/longhornetcat /var/run/ganesha.pidau-delà de 4 s ;engine-image-ei-b4bcf0a5-h9664porte 142 redémarrages.Schedulable: Falseau moment du relevé.Résilience : ce que la mesure permet, et ce qu'elle interdit
Direction du fondateur (2026-09-02) : « sortir de Longhorn est une possibilité. Ce serait bien d'avoir une solution résiliente tout de même. » Je n'exécute rien ici — je pose les chiffres et les options, l'arbitrage reste ouvert.
⚠ Un fait qui a changé de statut
Le
Chart.yamljustifiait le mode standalone par : « la donnée servie ici est DÉRIVÉE — le master d'une vidéo reste sur l'appareil de son propriétaire ». C'était vrai. Mais le produit promet désormais une sauvegarde automatique dès qu'un compte est ouvert : le bucket est la copie de secours de l'utilisateur.Ce que la grappe peut porter, mesuré
sda(USB, 465 Go)⚠ MinIO distribué en erasure coding est HORS DE PORTÉE : deux nœuds sur trois n'ont plus qu'un giga libre. Le
Chart.yamlavait raison sur ce point, et cette raison-là n'a pas bougé.⚠ Et les trois
sdasont des disquesGenericen USB, sur la même étagère, très probablement sur la même alimentation. Trois répliques là-dessus sont des pannes CORRÉLÉES : un incident électrique ou un concentrateur USB emporte les trois d'un coup. Ce n'est pas la résilience qu'on croit acheter — et c'est exactement le genre de couplage que ce ticket vient de démontrer sur le réseau.⚠⚠ Sortir MinIO de Longhorn ne répare RIEN pour les autres
15 volumes vivent sur Longhorn :
erp(50 Gi),erp-sandbox(50 Gi), Vault (2 × 10 Gi), ClickHouse (16 Gi), Prometheus (8 Gi), Redis, CrowdSec, Traefik,url-shortener,prospection,backups-rwx… MinIO n'en est qu'un. La cause première resterait entière pour les quatorze autres, et ils n'ont, eux, aucune sonde qui les réveillerait.C'est le point décisif : le sujet n'est pas « où mettre MinIO », c'est « Longhorn tient-il sur cette grappe ».
Les options, avec leur prix
local-path+ réplication de bucket vers un second MinIO sur pi3local-path+ réplication vers Cloudflare R2Ce que je recommanderais, et pourquoi
A d'abord, pas B ni C. Parce que le problème mesuré n'est pas « MinIO est mal placé » — c'est « quinze volumes reposent sur une couche qui perd ses répliques sur le réseau, et un seul d'entre eux a une sonde ». Déplacer MinIO réglerait le cas qui nous a fait mal et laisserait Vault, ClickHouse et l'ERP exactement où ils sont.
Et C mérite d'exister de toute façon, mais comme sauvegarde hors site, pas comme remplacement : trois répliques sur trois disques USB de la même étagère ne protègent contre aucun sinistre qui touche l'étagère. ⚠ Sa seule vraie question est produit, pas technique : la promesse faite à l'utilisateur sur où vit son travail (
app/lib/ou-vit-ton-travail.tscôté front).Décision au fondateur. Rien n'est engagé.