Some checks failed
verifier / verifier (push) Has been cancelled
La revision a commence par un balayage par motifs — chemins morts, cibles make absentes, comptes derives. Il a trouve une trentaine d ecarts et rate presque tout le reste : un motif ne voit que ce qui s exprime en motif. make hote-planifier en est l exemple. La cible EXISTE, donc le controle passait au vert. C est une cible depreciee qui refuse et sort en 2, recommandee par AGENTS.md, et qui contredit la REGLE D OR du meme fichier trois ecrans plus haut. Il fallait lire pour la voir. 74 documents lus un par un. 66 corriges, 8 exacts. CE QUI ETAIT FRANCHEMENT FAUX AGENTS.md, la source d autorite, annoncait la flotte pas encore executee contre des VM reelles. Elle a ete rasee et remontee depuis zero trois fois. ecosysteme-chezlepro.md, le document montre a un client, portait la meme phrase : il se sous-vendait gravement. courriel-conception.md s ouvrait sur aucun role n est encore ecrit, au-dessus de son propre paragraphe 1 qui les nomme. autorisation.md se terminait sur rien n est construit alors qu il rapporte des mesures datees du role en fonctionnement. hebergeur-exploitation.md disait rien n est fait d un depot qui existe. filiation-emancipation.md se contredisait a deux ecrans de distance. DES MODELES DECRITS D APRES UN MONDE ANTERIEUR Le resolveur : cinq documents decrivaient un Unbound par VM en opt-in, trois le donnaient en exemple d integration FACULTATIVE — il est universel depuis le 2026-08-24. L adressage de nomenclature-vm.md : reseau unique, VLAN 11-15, VMID a cinq chiffres. Le nommage SDN de sdn-evpn.md contre le code : c est le wiki qui avait raison. CE QUI CASSE AU PREMIER ESSAI Le nom du gabarit dore etait faux a quatre endroits, dont la procedure qui le FABRIQUE et le critere R2 de l epreuve d operateur independant. preparer-un-site-hebergeur.md avertissait qu une VM faite a la main serait detruite : raser derive du plan, il ne la detruira jamais — le risque est l inverse. Un mot de passe d essai en clair dans un depot public. DEUX PREUVES ETENDUES, ET UNE QUI SE TROMPAIT ELLE-MEME P57 couvre les groupes : elle a signale aussitot 29 groupes annonces au-dessus d un tableau qui en cite 40. P29 confronte le tableau de authentification.md aux declarations reelles : 12 annonces, 21 reels. Et P57 imposait un chiffre faux — 56 preuves alors que le depot en porte 57, la conditionnelle vivant hors de tout comptage. Un garde-fou qui fait respecter une erreur ajoute l assurance a l erreur. CE QUI RESTE, ET QU AUCUNE PREUVE NE TIENT Deux comptes trouves a la main. Et une lacune reelle : rien ne garde les meta/acces.yml — ni qu un service web-sso en porte un, ni que le groupe qu il nomme existe. P29 tient les positions d authentification, personne ne tient les habilitations. make prouver : CONFORME, 56 OK, 0 echec, 1 saute. 0 lien mort. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
114 lines
5.7 KiB
Markdown
114 lines
5.7 KiB
Markdown
# 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`) :
|
||
```yaml
|
||
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 :
|
||
|
||
```bash
|
||
# 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é.
|