Daniel Allaire
3cf00bbf3a
Aujourd'hui, tout ce qui fabrique Chezlepro vit sur `eregion` — une machine HORS FLOTTE, montee a la main, que Set-OPS ne deploie pas, ne sauvegarde pas et ne prouve pas. Un ecosysteme entier depend d'un point unique que le moteur ignore. Patient 0 le remplace par le plus petit ecosysteme COMPLET (PKI, DNS, edge, courriel, PostgreSQL, forge — six machines), bati par le moteur, sauvegarde par le moteur, verifie par le harnais. On ne deplace pas le point unique de defaillance : on l'elimine. Derive du modele `forge`, avec trois ecarts assumes : - INDEX 29 (10.29.0.0/16, VLAN 1291-1296), choisi libre : 13 lab, 17 Chezlepro, 23 Technolibre ; les index bas (1, 11) ont deja force deux renumerotages. - `federe: false` — patient 0 est EXCLU des devis du site tant qu'il n'est pas materialise. Une flotte en cours de reconstruction n'a pas a se voir reserver des VLAN et des regles pour un ecosysteme qui n'existe pas (c'est exactement ce qui avait injecte les adresses d'un tenant perime dans le pare-feu partage, le 2026-08-12). A basculer a `true` AVANT `make sdn-appliquer`, le jour du deploiement. - `forge-01` recoit 80G au lieu du defaut : elle hebergera les depots de TOUTE la lignee, pas seulement les siens. Le modele `forge` dont il derive etait lui-meme perime sur deux points, corriges ici : `client_pki` liste a la main alors que l'integration est devenue universelle, et un FQDN expose reste en `exemple.internal`. Les modeles PRIVES ne sont pas couverts par le harnais — P17 ne decouvre que le modele public. VERIFIE : les quatre registres valident, le gabarit de voute couvre les 20 secrets exiges, l'inventaire est genere et applique. Et sur l'instance de l'exploitant, en pleine reconstruction : `make verifier` -> 38 OK, 0 echec, 0 saute ; les devis ne voient toujours que Chezlepro et Technolibre. CE QUI N'EST PAS ICI, ET NE LE SERA JAMAIS : le mot de passe de la voute. C'est le seul objet que la reproduction exige d'un humain — le mettre dans la forge reviendrait a enfermer la cle dans le coffre. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
16 lines
849 B
YAML
16 lines
849 B
YAML
---
|
|
# Proxmox, cote TENANT : son gabarit dore et ses defauts de placement.
|
|
#
|
|
# L'API du cluster, ses noeuds, ses stockages et ses ponts appartiennent a l'HEBERGEUR
|
|
# et vivent dans SON depot (proxmox-hebergeur.yml, a cote d'underlay.yml). Recopies ici,
|
|
# ils avaient deja diverge entre tenants du meme cluster.
|
|
#
|
|
# Ce qui reste ici est un CHOIX de patient 0, fait a l'interieur de ce que l'hebergeur
|
|
# offre : quel modele cloner, sur quel noeud/stockage/pont poser ses VM par defaut.
|
|
# Ce sont les QUATRE valeurs qui rattachent un tenant a une fabric (D-80) : les seules
|
|
# a changer si patient 0 demenage. `make placement-plan` les confronte au cluster reel
|
|
# AVANT de deployer — quarante minutes de clone ne se rattrapent pas.
|
|
proxmox_clone_noeud: asgard
|
|
proxmox_clone_stockage: TrueNAS
|
|
proxmox_clone_pont: vmbr1
|
|
proxmox_clone_vmid_modele: 99998
|