---
# LE RUNNER D'UN TENANT — celui qui CONFIGURE.
#
# Le travail d'un runner se divise en trois portées, et chacune a son rôle :
#
#   calculer      plan -> inventaire        aucune voûte        `serveur_ops`
#   configurer    rôles sur ses machines    voûte du TENANT     CE RÔLE
#   matérialiser  créer/détruire des VM     voûte du SITE       `serveur_ops_site`
#
# CE QUI MANQUAIT (2026-08-26). La portée « configurer » était attribuée à `serveur_ops`
# dans la doctrine — mais rien ne déposait jamais la voûte du tenant sur son runner. Un
# runner pouvait donc dériver son inventaire et ne rien pouvoir en faire : chaque rôle qui
# demande un secret échouait sur son assertion, et l'échec ne disait pas qu'il manquait un
# FICHIER, seulement que les valeurs étaient vides.
#
# Découvert en préparant la reconstruction de Chezlepro : le runner du SITE peut
# matérialiser ses quinze machines, mais ne peut pas les configurer — Chezlepro a sa
# PROPRE autorité de certification, donc `client_pki` y réclame 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'hébergement mutualisé défendable.
#
# POURQUOI UN RÔLE À PART, et non une option de `serveur_ops`. Donner sa voûte à un runner
# est un POUVOIR, pas un réglage. Le déclarer explicitement au plan force à répondre à la
# question « cette machine a-t-elle le droit de configurer cet écosystème ? » — alors
# qu'une option activée par défaut y répondrait à notre place. C'est le même patron que
# `serveur_artefacts` + `serveur_cache_site` : un installateur, puis un marqueur qui
# ajoute un pouvoir.
#
# QUI PEUT LE DÉCLARER : l'écosystème lui-même, pour SA machine. Un runner de SITE ne le
# déclare jamais — il porte les plans des tenants en `role: tenant` précisément pour dire
# qu'il prépare leur terrain sans les piloter.

serveur_ops_tenant_utilisateur: "setops"
serveur_ops_tenant_racine: "/opt/setops"

# Le dossier du dépôt de CET écosystème chez le runner, cloné par `serveur_ops`
# (entrée `role: instance` de `serveur_ops_depots`). Par défaut : celui que le lien
# `instance` désigne déjà — le pilote et sa voûte ne peuvent pas viser deux écosystèmes.
serveur_ops_tenant_depot: "{{ serveur_ops_instance | default('') }}"

# --- LA VOÛTE DU TENANT ------------------------------------------------------
#
# Déposée CHIFFRÉE, jamais en clair. Le mot de passe n'est pas stocké : l'exploitant le
# tape au moment d'agir.
#
# `decrypt: false` EST OBLIGATOIRE sur la copie. Sans lui, Ansible DÉCHIFFRE la source
# quand il détient le mot de passe — mesuré le 2026-08-24 sur la voûte du site, 776 octets
# en clair au lieu de 3465 chiffrés, sur une machine où ils n'avaient rien à faire.
serveur_ops_tenant_voute_source: ""
serveur_ops_tenant_voute_deposer: true

# LE DOSSIER D'INVENTAIRE SE DÉCOUVRE, il ne s'écrit pas. Le dépôt en connaît deux noms
# — `principal` et `production` — et l'ordre de préférence est celui de
# `inventory_rules.dossier_inventaire`. Écrire le nom en dur ici le ferait mentir pour
# l'écosystème qui emploie l'autre.
serveur_ops_tenant_inventaires_connus:
  - principal
  - production