Set-OPS-Public/docs/dimensionnement-ressources.md

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) :

1. Valeur explicite par hôte dans serveurs.yml (coeurs / memoire / disque) — gagne toujours.
2. 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	repli aujourd'hui vide d'effet : tous les groupes de service ont leur rôle. Voir l'encadré plus bas.
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

1. scripts/inventory_rules.py — deriver_ressources(groupes_service, racine_roles) lit les empreintes et calcule.
2. 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).
3. scripts/inventory_host.py — parametres-proxmox émet SETOPS_COEURS / SETOPS_MEMOIRE / SETOPS_DISQUE lus par make creer-vm.
4. Makefile (creer-vm → cloner-vm) relaie vers proxmox_clone_coeurs / proxmox_clone_memoire.
5. 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).

Les empreintes : ne pas les recopier, les mesurer

Ce document a porté jusqu'au 2026-09-06 un tableau de quatorze empreintes recopiées à la main. Il y en a 32 aujourd'hui, et l'une des quatorze avait cessé d'être vraie. Recopier une valeur qui vit ailleurs, c'est s'engager à la suivre — cette page ne s'y engage plus :

# l'empreinte de chaque logiciel, telle qu'elle est déclarée
python3 - <<'EOF'
import yaml, pathlib
for f in sorted(pathlib.Path('roles').glob('*/meta/empreinte.yml')):
    e = (yaml.safe_load(f.read_text()) or {}).get('setops_empreinte') or {}
    print(f"{f.parts[1]:26} {e.get('coeurs')} coeur(s)  {e.get('memoire_mo')} Mo  {e.get('disque_go')} Go")
EOF

# ce que ça donne pour un hôte donné, une fois sommé et arrondi
make hote-afficher HOTE=obs-01

Ce qui mérite d'être écrit ici, c'est ce qui façonne le calcul et ne se lit pas dans un rôle — le socle, les marges, les paliers, les bornes. Ils sont au §« Règles d'agrégation » ci-dessus, et vivent en tête de scripts/inventory_rules.py.

Un repli devenu inutile. EMPREINTES_SANS_ROLE couvrait serveur_web_frontal et serveur_web_dorsal du temps où ces groupes n'avaient pas de rôle. Ils en ont un depuis, avec leur propre meta/empreinte.yml — et comme la précédence est rôle > repli > défaut, ces deux entrées ne sont plus jamais lues. Elles disent d'ailleurs autre chose que les rôles (5 Go contre 10 pour le frontal) : c'est sans effet, mais c'est le genre d'écart qu'on croit lire comme une vérité.

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é.