2 Commits

Include renames

Author	SHA1	Message	Date
arcodangeandClaude Opus 5	6d09adab0c	feat(minio) — un téléversement abandonné laisse des parts que RIEN ne montre, et le plafond du tunnel est enfin mesuré ... ## Le plafond, mesuré — la section du README qui disait « à vérifier » ne le dit plus `minio/README.md` portait : « ce plafond n'a PAS été mesuré ici, il doit l'être avec un vrai téléversement avant d'annoncer une limite aux utilisateurs ». Sonde par PUT NON SIGNÉ vers le bucket : rien ne s'écrit, et les deux réponses se distinguent proprement — un 403 vient de MinIO (le corps a donc traversé le tunnel), un 413 vient du tunnel. 100 Mio → 403 corps passé 101 Mio → 413 refusé par le tunnel ⚠ Le plafond est EXACTEMENT 100 Mio, alors que kadans-api annonçait 200 Mio. ⚠ Et la parade retenue n'est PAS celle que le README recommandait. Ramener le gabarit sous le plafond aurait aussi fermé les cours longs (~29 min au palier « travail »). C'est le téléversement en PARTS qui a été livré (kadans-api #188). ## Ce que ça crée comme déchet, et à qui il appartient Un téléversement en parts jamais refermé laisse ses parts dans le bucket : `mc ls` n'en dit rien, la console non plus, aucun objet ne les montre. Une fuite qui ne se voit qu'à la facture — ou à la saturation d'un volume de 50 Gi. L'app abandonne ce qu'elle ouvre quand elle échoue en route. Elle ne peut PAS rattraper le navigateur qui ferme l'onglet. ⚠ LE README DU MODULE DISAIT « il ne pose ni quota, ni règle de cycle de vie » — et cette règle-ci ne le contredit pas, elle en précise la frontière. La question qui tranche est « à QUOI cette connaissance appartient-elle ? » : - une EXPIRATION DE CONTENU (« ces vidéos se purgent à 90 jours ») demande de connaître le produit. Elle est chez l'app ; - un téléversement incomplet n'est le contenu de PERSONNE. Aucune app ne veut le garder, aucune ne peut le voir depuis son code. C'est un déchet de PROTOCOLE, produit par le mécanisme même du bucket : il est chez celui qui crée les buckets. Test pratique écrit au README : si répondre à « combien de temps ? » exige de connaître le produit, c'est chez l'app. Ici la réponse n'exige que de connaître S3 — passé l'expiration des URL signées (2 h côté kadans-api), un téléversement ne peut plus RIEN recevoir. D'où 1 jour, douze fois la marge, et pas 7. ⚠ Non paramétrable (YAGNI) : un seul cas. Le déclencheur pour en faire une variable est écrit — une app qui signerait des parts au-delà de 24 h. ## ⚠ Ce réglage-ci fonctionne, contrairement au CORS par bucket MinIO communautaire stubbe `PutBucketCors` en 501 (`cmd/dummy-handlers.go`), ce qui avait déjà coûté une tentative d'IaC — c'est écrit dans le `iac/main.tf` du dépôt front. Les handlers de CYCLE DE VIE, eux, n'y figurent PAS : vérifié à la source avant d'écrire une ligne, pour ne pas répéter exactement cette erreur. ## Le plancher de version, et pourquoi il est là `abort_incomplete_multipart_upload` est apparu en **3.10.0** — mesuré en interrogeant le schéma du provider version par version (3.9.0 ne l'a pas, 3.10.0 l'a). Le module déclare donc `>= 3.10.0` LUI-MÊME. ⚠ Sans ce plancher, un appelant resté sur 3.3.0 échouerait au plan sur un « unsupported block type » qui ne dit pas qu'il faut monter de version. Avec, il lit dès `tofu init` : « no available releases match the given constraints 3.3.0, >= 3.10.0 ». ## ⚠ ORDRE DE FUSION Cette PR fait passer tout appelant du module sous le plancher 3.10.0. Le dépôt `kadans` épingle encore 3.3.0 : **son bump doit atterrir AVANT celle-ci**, sinon son apply casse entre les deux fusions. ## Preuve `tofu validate` contre le schéma RÉEL du provider 3.10.0, module instancié depuis un bac à sable (aucun backend, aucun appel à MinIO ni Vault) : « Success! The configuration is valid. » Et le plancher a été éprouvé plutôt que relu : épinglé à 3.3.0, `tofu init` rend bien le refus cité ci-dessus. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-20 20:06:02 +02:00
arcodangeandClaude Opus 5	ec71571b98	refactor(minio) — chacun son périmètre : les buckets se déclarent depuis le dépôt de l'app ... « Les buckets sont à déclarer dans le repo de kadans-api. On ne va pas modifier le repo tools à chaque changement d'application. Chacun son périmètre. Tools peut proposer un module pour standardiser la déclaration de buckets à la limite, mais c'est tout. » (fondateur, 26/07) C'est une erreur de fond de ma part : j'avais fait de `tools` le PROPRIÉTAIRE de déclarations qui appartiennent aux applications. À ce rythme, chaque nouveau bucket de n'importe quelle app devenait une PR sur l'infra partagée. CE QUI CHANGE. `consumers.tf` disparaît, et la liste de buckets du chart se vide. À la place, un module réutilisable `iac/modules/minio_app` : une app lui donne son nom et ses buckets, et reçoit des buckets privés, un compte de service qui ne peut rien toucher d'autre, et ses clés dans `kvv2/minio/<app>`. L'OBSTACLE, ET SA RÉPONSE. Déclarer ses buckets depuis son propre dépôt suppose des droits d'ADMINISTRATION sur MinIO. Confier le root serait absurde : il lit et écrit tous les objets de toutes les apps. `tools` fournit donc un compte PROVISIONNEUR aux droits minimaux — créer un bucket, une politique, un compte de service — et AUCUN droit sur les objets. Une app compromise pourrait créer des buckets (une nuisance), pas lire les vidéos d'une autre. Le root, lui, ne sort toujours pas de ce pipeline. Le rôle CI de chaque app gagne la lecture de `kvv2/data/minio/provisioner` dans `app_policy` — générique, et c'est exactement le genre de standardisation qui appartient au dépôt commun. ⚠ CE QUE JE N'AI PAS PU PROUVER : les noms d'actions d'administration MinIO de la politique du provisionneur viennent de la documentation, pas d'un essai — je n'ai pas d'identifiants admin en main. Le premier `apply` les confirmera ou les corrigera. C'est le seul point non vérifié de cette PR, et il est signalé dans le code à l'endroit exact. tofu fmt propre · tofu validate réussi sur minio/iac ET hashicorp-vault/iac. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA	2026-07-26 10:07:05 +02:00