Daniel Allaire
b7c06755dd
`etat: planifie` etait l'heritage du modele : `flotte-creer` ne cree que les hotes ACTIFS, donc le deploiement n'aurait fabrique aucune machine. Passer a `actif` est la declaration d'intention — « je veux que cette machine existe » — et c'est le seul geste qui la transforme en VM. L'inventaire regenere ne porte plus que trois integrations : client_backup, client_pki, client_unbound. `client_journal` et `client_metrique` sont tombes d'eux-memes — patient 0 n'a ni Loki ni Prometheus, et le moteur sait desormais qu'une integration universelle sans service central n'a personne a qui parler. Dependances causales : OK. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
16 lines
1 KiB
YAML
16 lines
1 KiB
YAML
---
|
|
# `integrations:` ne porte que les integrations FACULTATIVES. Les universelles
|
|
# (PKI, metriques, journaux, resolution locale) viennent de la politique du role —
|
|
# voir roles/client_*/meta/integration.yml : tout hote les recoit sans etre listee ici.
|
|
serveurs:
|
|
infra-pki-01: { fonction: infra-pki, etat: actif, disque: 32G, integrations: [client_backup] }
|
|
infra-edge-01: { fonction: infra-edge, etat: actif }
|
|
infra-dns-01: { fonction: infra-dns, etat: actif, disque: 40G }
|
|
# PAS DE `client_smtp` ICI, ni ailleurs dans ce plan : patient 0 n'a pas de MTA, et la
|
|
# dependance causale refuserait le deploiement. Porter des depots n'exige pas d'envoyer
|
|
# du courriel. Le jour ou la forge devra notifier, ce sera un relais declare, pas une
|
|
# integration orpheline.
|
|
#
|
|
# LA MACHINE QUI PORTE LE GENOME. Son disque n'est pas celui du modele : elle
|
|
# hebergera les depots de TOUS les ecosystemes de la lignee, pas seulement les siens.
|
|
forge-01: { fonction: forge, etat: actif, disque: 80G, integrations: [client_backup] }
|