Set-OPS-Public/roles/serveur_ops_tenant/meta/flux.yml

---
# Flux réseau du runner de TENANT. Voir docs/flux-conception.md.
#
# AUCUN FLUX PROPRE, ET C'EST LE POINT. Ce rôle ne fait que déposer un fichier ; ce qui
# consomme la voûte, c'est `serveur_ops` quand il configure les machines de l'écosystème,
# et ses flux sont déclarés chez lui. Ce rôle n'atteint NI la fabric NI la frontière —
# c'est exactement ce qui le sépare de `serveur_ops_site`.
#
# Le dire explicitement plutôt que d'omettre le fichier : une absence de déclaration se
# lit comme un oubli, une déclaration vide se lit comme une décision.
flux: []
runner : `serveur_ops_tenant` — le runner d'un tenant recoit enfin sa voute La doctrine des runners decrit trois portees depuis le 2026-08-22 : calculer plan -> inventaire aucune voute serveur_ops configurer roles sur ses machines voute du TENANT <- revendiquee, jamais recue materialiser creer/detruire des VM voute du SITE serveur_ops_site La deuxieme ligne etait un trou. RIEN ne deposait jamais la voute d'un tenant sur son runner. Un runner pouvait deriver son inventaire et ne rien pouvoir en faire : chaque role qui demande un secret echouait sur son assertion, et l'echec ne disait pas qu'il manquait un FICHIER, seulement que les valeurs etaient vides. Decouvert en preparant la reconstruction de Chezlepro. Le runner du SITE peut materialiser ses quinze machines ; il ne peut pas les configurer, parce que Chezlepro a sa PROPRE autorite de certification — donc `client_pki` y reclame un secret de Chezlepro. Le runner du site ne l'a pas, et NE DOIT PAS l'avoir : c'est la ligne qui rend l'hebergement mutualise defendable. `serveur_ops_tenant` est le symetrique exact de `serveur_ops_site` : un MARQUEUR, pas un installateur. Il depose la voute `decrypt: false`, puis RELIT l'en-tete du fichier depose — une voute dechiffree par accident est une fuite silencieuse. Le dossier d'inventaire (`principal` ou `production`) se DECOUVRE sur la machine plutot que d'etre ecrit. Pourquoi un role a part et non une option de `serveur_ops` : donner sa voute a un runner est un POUVOIR, pas un reglage. Le declarer au plan force a repondre a « cette machine a-t-elle le droit de configurer cet ecosysteme ? » — une option activee par defaut y repondrait a notre place. CHEZLEPRO LISAIT ENCORE SON GENOME CHEZ PATIENT 0. Trouve au passage, et bloquant pour la reconstruction : `serveur_ops_forge_amont` pointait sur `10.29.16.11` — la forge de patient 0, l'amont d'avant que le site ait la sienne. D-81 a tranche depuis. Laisse tel quel, Chezlepro se serait reconstruit depuis un moteur perime, sur un reseau que le decoupage en zones a de toute facon deplace. Corrige vers la forge du site, PAR SON IP — `forge.genese.internal` appartient a la zone souveraine du site, et un tenant ne resout que la sienne ; le certificat SERVI porte bien `IP Address:10.0.33.11`. La racine de l'AC du site est desormais versionnee a cote de la carte de la fabric a laquelle elle appartient, et son chemin se DERIVE du symlink `underlay.yml` : il vaut depuis le poste comme depuis un runner. Le role est inscrit dans les quatre registres qui l'exigeaient — couches de deploiement, graphe des dependances, catalogue des services, carte d'orientation. Ce sont les preuves P08, P38 et P48 qui l'ont reclame, chacune a son tour. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> 2026-08-26 15:30:51 -04:00			`---`
			`# Flux réseau du runner de TENANT. Voir docs/flux-conception.md.`
			`#`
			`# AUCUN FLUX PROPRE, ET C'EST LE POINT. Ce rôle ne fait que déposer un fichier ; ce qui`
			# consomme la voûte, c'est `serveur_ops` quand il configure les machines de l'écosystème,
			`# et ses flux sont déclarés chez lui. Ce rôle n'atteint NI la fabric NI la frontière —`
			# c'est exactement ce qui le sépare de `serveur_ops_site`.
			`#`
			`# Le dire explicitement plutôt que d'omettre le fichier : une absence de déclaration se`
			`# lit comme un oubli, une déclaration vide se lit comme une décision.`
			`flux: []`