|
Some checks are pending
verifier / verifier (push) Waiting to run
Remarque de l'exploitant en preparant patient 0 : « le pont ne me semble pas approprie du tout, depuis qu'on cree des VNets pour des tenants ». Juste, et plus grave que cosmetique. `make placement-plan` confrontait `proxmox_clone_pont` (vmbr1) au cluster. Ce n'est PAS la que les VM de la flotte atterrissent : `instancier` pose dans chaque hote le pont DERIVE de sa zone (le VNet du tenant), et `make creer-vm` le passe au clone en ecrasant ce defaut. vmbr1 n'est que le repli des clones MANUELS, hors plan. Le devis mesurait donc un objet qui ne sert pas, et ignorait celui qui sert. SUR PATIENT 0 : avant, « pont vmbr1 existe -> CONFORME ». Apres, « reseaux VM : t29appl, t29donn, t29fron, t29serv INTROUVABLE — passer `make sdn-appliquer` AVANT de creer les VM ». Aucun de ses quatre VNets n'existe sur le cluster : le devis d'avant-vol declarait conforme un tenant dont les VM n'auraient eu nulle part ou naitre. D-80 avait pourtant ete corrigee le 2026-08-13 — la liaison de placement est noeud, stockage et gabarit, le pont se derive. Le devis continuait de compter quatre objets et de nommer le mauvais : une doctrine corrigee dans un document ne se propage pas toute seule dans le code qui l'applique. MESURE MAINTENANT : en `sdn`, les VNets derives confrontes a /cluster/sdn/vnets ; en `switch`, les ponts du noeud retenu. Avec le geste correctif quand il en manque. NON-REGRESSION sur l'ecosysteme de reference : ses six VNets existent, conforme, code 0. Quatre tests (Cluster simule, aucun reseau touche), harnais 38/38. Au passage, dans patient 0 : le commentaire annoncait « les QUATRE valeurs qui rattachent un tenant a une fabric » — trois, et le pont n'en est pas. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| test_adressage_derive.py | ||
| test_devis_placement.py | ||
| test_gui_intrants.py | ||
| test_inventory_host.py | ||
| test_raser.py | ||
| test_raser_resultat.py | ||