Daniel Allaire ac85278366 preuve : P34 — chaque document declare son lecteur (D-74)

La refonte de ce matin posait une convention. Une convention qu'on n'outille
pas tient tant que quelqu'un y pense : c'est le raisonnement de D-70, applique
au corpus documentaire.

Etat de depart mesure : 2 documents sur 34 declaraient leur lecteur. Les 32
autres disaient leur SUJET — ce qui avait enfoui le runbook de reprise le plus
utile du depot au §6 de autorisation.md.

Les 38 le declarent desormais, lecteur determine document par document et non
colle au gabarit : l'exploitant (devis, migration de tenant, cycle de vie,
gabarit d'or), le mainteneur (conceptions, registres, carte), le lecteur
externe (ecosysteme-chezlepro), l'agent IA (MISE-A-JOUR-CODEX-CLAUDE).

Deux exemptions DERIVEES, pas listees — un chemin en dur aurait vieilli a la
premiere page ajoutee : un document qui s'annonce genere, et un fragment sans
titre. Les 13 exemptes verifies un par un ; aucun document ecrit a la main
n'est exempte par accident. La preuve ne lit que l'EN-TETE, ce qui empeche
frontiere-opnsense.md et plan-et-generation.md — qui parlent de generation
dans leur corps — d'etre exemptes a tort.

Eprouvee dans les deux sens. Elle a echoue seule des sa premiere execution en
nommant deux documents que mon inventaire avait manques (docs/audit/). Puis
test negatif delibere : declaration retiree de meta-classe.md -> ECHEC la
nommant ; restauree -> OK.

Ce qu'elle ne teste pas : que le lecteur declare soit le BON. Ca se juge en
revue ; elle garantit qu'on a du y penser.

P01–P34. Comptes perimes corriges au passage (AGENTS.md et devis-services.md
annoncaient encore 30 preuves).

Verifie : prouver.py 0 (34 OK), plan-recette inchange.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-10 07:53:04 -04:00

4.7 KiB

Raw Blame History

Dimensionnement dérivé des ressources VM

Pour qui : le mainteneur — comment les ressources d'une VM se dérivent des logiciels qu'elle porte.

Ce document décrit comment Set-OPS estime les ressources d'une VM (cœurs, RAM, disque) à partir des propriétés des logiciels qu'elle héberge et du socle SE, plutôt que de laisser chaque clone hériter aveuglément des specs du golden template.

Décision actée le 2026-06-25 : extension assumée de la modélisation du plan de contrôle (cf. positionnement.md). C'est le prolongement naturel de la dérivation réseau (nomenclature.yml) — du dimensionnement, pas une fonction de type NetBox.

Principe

ressources(VM) = socle_SE  +  Σ empreinte(logiciel hébergé)  → marge → arrondi

Précédence (du plus fort au plus faible) :

Valeur explicite par hôte dans serveurs.yml (coeurs / memoire / disque) — gagne toujours.
Valeur dérivée (socle + empreintes + marge + arrondi) sinon.

Comme Ansible/Proxmox sont idempotents, ajuster une empreinte puis régénérer ne fait que recalculer la cible ; aucune dérive silencieuse.

Où vit chaque donnée

Donnée	Emplacement	Remarque
Empreinte d'un logiciel	`roles/<groupe>/meta/empreinte.yml`	Propriété du logiciel, voyage avec le rôle. Fichier pur données (parsable sans Jinja).
Groupes sans rôle dédié	`EMPREINTES_SANS_ROLE` dans `scripts/inventory_rules.py`	p. ex. `serveur_web_frontal`, `serveur_web_dorsal`.
Repli ultime	`EMPREINTE_DEFAUT`	groupe inconnu : empreinte minimale.
Socle SE	`SOCLE_SE` dans `inventory_rules.py`	coût de base Debian durci.
Override par hôte	`serveurs.yml` (`coeurs`/`memoire`/`disque`)	déjà supporté par le générateur (`PLACEMENT`).
Politique (marges, paliers, plafonds)	constantes en tête de `inventory_rules.py`

Format d'une empreinte (roles/<rôle>/meta/empreinte.yml) :

setops_empreinte: { coeurs: 2, memoire_mo: 2048, disque_go: 20 }

Règles d'agrégation (valeurs en vigueur)

Socle SE : 1 cœur / 512 Mo / 8 Go.
RAM : (socle + Σ rôles) × 1.20, arrondie au palier 512 Mo, min 1024 Mo.
Disque : (socle + Σ rôles) × 1.25, arrondi au palier 5 Go, min 12 Go, émis sous la forme "<n>G".
Cœurs : max(socle, Σ rôles), entier, min 1, plafond 8 (CPU burstable : ni additif strict, ni marge).

Seuls les groupes de service de l'hôte (issus de applications.yml) entrent dans la somme. Le socle (serveur_debian/serveur_durci) et les groupes d'état sont exclus.

Chaîne technique

scripts/inventory_rules.py — deriver_ressources(groupes_service, racine_roles) lit les empreintes et calcule.
scripts/instancier.py — pour chaque hôte, écrit proxmox_coeurs, proxmox_memoire, proxmox_disque_taille dans l'inventaire généré (via setdefault : un override serveurs.yml prime).
scripts/inventory_host.py — parametres-proxmox émet SETOPS_COEURS / SETOPS_MEMOIRE / SETOPS_DISQUE lus par make creer-vm.
Makefile (creer-vm → cloner-vm) relaie vers proxmox_clone_coeurs / proxmox_clone_memoire.
playbooks/proxmox/cloner_vm_debian.yml — passe cores/memory à proxmox_kvm (avec omit si absent : aucune régression, on garde alors les specs du template).

Empreintes actuelles

Rôle	cœurs	RAM (Mo)	disque (Go)
serveur_step_ca	1	256	2
serveur_powerdns	1	512	2
serveur_nginx	1	512	3
serveur_openldap	1	512	3
serveur_keycloak	2	1536	5
serveur_postgresql	2	2048	20
serveur_redis	1	512	2
serveur_forgejo	1	1024	20
serveur_prometheus	1	1024	20
serveur_loki	1	1024	20
serveur_grafana	1	512	2
serveur_icinga	2	1024	10
serveur_web_frontal (repli)	1	512	5
serveur_web_dorsal (repli)	1	1024	10

Ajuster

Une empreinte de logiciel : éditer roles/<rôle>/meta/empreinte.yml.
Un hôte précis : poser coeurs/memoire/disque sur le serveur dans serveurs.yml (l'override prime sur la dérivation).
La politique (marges, paliers, socle, plafond) : constantes en tête de inventory_rules.py.

Puis : make instancier (voir le diff), make instancier-appliquer (FORCE=1 si changement intentionnel).

Limite connue

Les ressources s'appliquent à la création de la VM (clonage). Modifier une empreinte n'ajuste pas automatiquement une VM déjà existante : il faut un re-clonage ou un redimensionnement Proxmox manuel. Le plan, lui, reste la source de vérité et se régénère à volonté.

4.7 KiB Raw Blame History Unescape Escape