---
# INTÉGRATION CLIENTE : désigner le résolveur de l'écosystème.
#
# CE RÔLE N'INSTALLE PLUS RIEN (2026-08-24). Il posait un Unbound sur CHAQUE VM — N démons
# identiques, ~21 Mo chacun, pour quelques centaines de requêtes. Le résolveur est
# désormais un service du tenant (`serveur_resolveur`), et ce rôle ne fait plus qu'une
# chose : écrire `/etc/resolv.conf`.
#
# L'ancien nom mentait dès lors qu'il n'installait plus Unbound — d'où `client_resolveur`.

# DÉRIVÉ de l'inventaire : l'hôte qui porte le résolveur. Aucun résolveur au plan rend une
# valeur vide, et le rôle ne touche à rien (voir `client_resolveur_actif`).
client_resolveur_hote: >-
  {{ (groups['serveur_resolveur'] | default([]) | first | default('')) }}
client_resolveur_adresse: >-
  {{ hostvars[client_resolveur_hote].ansible_host | default('')
     if client_resolveur_hote else '' }}

# L'INTÉGRATION SUIT L'EXISTENCE DU SERVICE — elle ne se déclare pas. Un écosystème sans
# résolveur garde la résolution d'amorçage posée par cloud-init : c'est un choix valide,
# pas une panne.
client_resolveur_actif: "{{ (groups['serveur_resolveur'] | default([])) | length > 0 }}"

client_resolveur_zone_interne: "{{ domaine_interne }}"
client_resolveur_resolv_conf: "/etc/resolv.conf"

# --- BASCULE PROTÉGÉE ---------------------------------------------------------
#
# Réécrire /etc/resolv.conf peut couper toute la flotte si la cible est mauvaise. Le rôle
# exige donc une confirmation ET vérifie que le résolveur répond DÉJÀ — pour l'interne et
# pour l'Internet — avant de basculer quoi que ce soit.
client_resolveur_apply: false
client_resolveur_confirm: false
client_resolveur_attente_reconnexion: 120