verifier / verifier (push) Waiting to run

Details

GUI : la vue Nomenclature, et deux fautes que mes bancs ne voyaient pas

LA VUE. La nomenclature etait le seul registre que le GUI ne savait pas
ecrire du tout : ajouter une fonction exigeait d ouvrir le YAML. Elle a
sa vue, et son formulaire est GENERE depuis le schema. Deuxieme registre
sur six. couverture_gui verifier passe : les 28 champs des plans reels
sont editables.

Elle n est pas un registre comme les autres : elle decrit la REGLE dont
VMID, VLAN, adresse et passerelle se derivent. Chaque fonction montre ce
qu elle derive et les VM qui la portent ; l index est montre mais pas
editable, parce qu il est alloue par le site ; valider_nomenclature
refuse de retirer une fonction encore portee, ou de designer une zone
non declaree.

DEUX FAUTES, ET POURQUOI MES BANCS NE LES VOYAIENT PAS.

Le formulaire des bases, livre la veille, etait casse dans un navigateur.
Il lisait data.schema, or il n existe aucun data global : c est une const
locale de charger(). ReferenceError a l ouverture, et zone morte dans
sauvegarderBases. Je l avais eprouve sous node EN LUI PASSANT data : le
banc reproduisait la fonction, pas sa portee. D ou test_rendu_gui.py, qui
charge le JS entier dans un DOM simule et dessine les douze vues, avec son
controle negatif.

Le schema decrivait reservations comme une table de zones ; le fichier
reel est un bloc plat. P61 comparait des NOMS aplatis, donc ne voyait
rien. Elle compare desormais aussi la FORME.

ECRIRE SANS DEPLACER UN COMMENTAIRE. _fusion_chirurgicale remplace le
bloc entier des qu une valeur change : quinze entrees compactes devenaient
42 lignes, et le commentaire du poste d exploitation se retrouvait en tete
du bloc, ou il affirmait que collab etait le poste d exploitation. Un
commentaire deplace n est pas laid, il est faux. _fusion_table edite les
tables ligne a ligne ; le diff fait trois lignes.

Au passage : sort_keys triait le schema, donc l ordre des cases a l ecran
(reserve_max avant reserve_min) ; et _ecrire_index_nomenclature ecrivait
encore par write_text, oubliee au passage des ecritures atomiques.

LIMITE : deux registres sur six sont generes, et je n ai toujours pas
ouvert cette page dans un navigateur.

make prouver : CONFORME, 60 OK, 0 echec, 1 saute.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q

2026-09-08 17:08:45 -04:00

8.2 KiB

Raw Blame History

Le GUI (console d'exploitation)

Unité d'apprentissage. Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer.

① Le concept (générique)

Un moteur d'infrastructure a besoin d'une interface humaine — sinon il n'est utilisable que par son auteur (ou une IA). Le principe fondateur : un opérateur doit tout piloter seul, sans l'auteur et sans IA (« exploitable sans IA »).

Une bonne console d'exploitation obéit à trois règles :

Elle édite la SOURCE, pas l'artefact. On modifie le plan (l'état voulu), jamais l'inventaire généré. La console montre la vérité, elle ne la contourne pas.
Elle prévisualise avant d'agir. dry-run (voir ce qui changerait) avant apply (changer).
Elle empêche l'invalide. Le meilleur garde-fou n'est pas un message d'erreur : c'est une interface où l'erreur est impossible à saisir.

② Comment Set-OPS le fait

make inventaire-ui lance une console web locale (127.0.0.1, protégée par un jeton). Ses vues :

Vues éditables (le plan)	Vues dérivées (lecture seule)
Serveurs · Intégrations · Applications · Bases · Domaines · Nomenclature · Intrants	Flux · Couches · Réseau (flotte + devis)

Le flux d'exploitation, de bout en bout :

Éditer une vue du plan → Sauvegarder ;
« Appliquer le plan » → régénère l'inventaire (VMID/IP/VLAN dérivés) ;
Vérifier (dry-run) sur un hôte → prévisualise sans rien changer ;
Déployer → applique les rôles (confirmation renforcée si l'instance est en PROD) ;
Créer la VM → clone sur Proxmox depuis le plan.

L'erreur rendue impossible. Le champ « Hôte » d'une application est un <select> qui ne propose que des hôtes réels : impossible de pointer vers un hôte fantôme. La console couvre le schéma du plan — et la preuve P19 le vérifie.

Les formulaires sont GÉNÉRÉS. Depuis le 2026-09-08, les vues Bases et Nomenclature ne portent plus de formulaire écrit à la main : elles le construisent depuis docs/audit/schema-plan.json, lui-même dérivé des constantes du moteur (make schema). Un champ ajouté au plan apparaît donc à l'écran sans qu'on touche à l'interface, et la preuve P61 refuse qu'un champ des plans réels manque au schéma — ou que le schéma décrive une forme que les plans n'ont pas.

La flotte, dans la vue Réseau. Voir toutes les instances, basculer (« Activer »), créer une instance depuis un modèle, repérer une collision d'index. Cf. Multi-instance & fédération.

Les vues, annotées

Chaque figure porte ses repères (pastilles + légende). Les vues éditables d'abord (le plan), puis les vues dérivées (lecture seule) :

Serveurs (éditable) — inventaire actif et état de la flotte ; cartes serveur et tuiles VMID/IP/VLAN dérivées du seed ; formulaire Identité = le seul endroit où l'on édite le plan.

Nomenclature (éditable) — le modèle dont tout l'adressage dérive : zones de sécurité, fonctions (catégorie · service), réservations. Chaque fonction montre ce qu'elle dérive — zone, VLAN, sous-réseau, bloc d'hôtes — et les VM qui la portent ; on ne retire pas une fonction encore portée. L'index y est affiché mais pas éditable : il est alloué par le site, pas décidé par le tenant (cf. l'en-tête de plan/nomenclature.yml), et s'édite depuis le panneau Intrants.

Applications (éditable) — catalogue des applis, éditeur (rôle · hôte · port · FQDN exposé), relations déclaratives (requiert · liens · bases), dépendances causales.

Bases — serveur (éditable) — les moteurs SGBD et les bases applicatives « nom @ serveur », avec les bases hébergées sur chaque serveur.

Bases — fiche (éditable) — portée · consommateur · serveur, secret Vault (jamais en clair, un pointeur seulement) et le DSN dérivé (secret masqué).

Domaines (éditable) — zones DNS publique vs interne, autorité · edge · DNSSEC, expositions.

Intégrations (éditable) — la matrice serveurs × intégrations. Les colonnes ✓ vertes sont la politique des rôles : elles s'appliquent à tout hôte et ne se décochent pas ; un — barré signale une exemption dérivée du service rendu (l'AC ne s'enrôle pas auprès d'elle-même). Les autres colonnes sont de vrais choix, cochables ici. La ligne couverture ne juge pas — elle rend le motif visible : c'est au lecteur de savoir si les manquants sont des décisions ou des oublis.

Cette vue existe parce que la fiche de détail ne montrait les intégrations que d'un serveur à la fois. Deux serveurs sans supervision ni journaux sont restés invisibles jusqu'à ce qu'un devis de pare-feu les énumère : l'information était à l'écran, répartie sur quatorze clics.

Flux (dérivée) — la matrice d'audit : la source de nftables et la justification lisible de chaque flux (sens ingress/egress, chiffrement).

Couches (dérivée) — l'ordre de déploiement en 6 couches, du socle aux agents ; celui que make deployer-tout déroule.

Réseau (dérivée) — la flotte multi-instances : adressage dérivé du seed, bascule d'instance, devis de configuration des switches.

Chaque figure est un SVG auto-contenu (la capture y est intégrée) : un seul fichier portable qui rend tel quel dans le wiki, un .md du dépôt, ou un navigateur.

③ Pourquoi c'est transférable

Set-OPS	Équivalents ailleurs
GUI au-dessus d'Ansible	AWX / Ansible Automation Platform, Semaphore
éditer la source de vérité	l'UI de NetBox (IPAM/DCIM), une CMDB
dry-run → apply	`terraform plan/apply`, tout panneau IaC
l'invalide impossible à saisir	validation à la source, formulaires contraints

Tu as appris la console d'exploitation, éditer-la-source, dry-run-avant-apply, la validation à la saisie — pas « le GUI de Set-OPS ».

④ À toi de jouer

Lance-la. make inventaire-ui, ouvre l'URL affichée. Repère l'inventaire actif et l'état de la flotte (en haut), les onglets, « Appliquer le plan », « Sauvegarder ».
Édite → prévisualise. Vue Serveurs, change la mémoire d'un hôte, Sauvegarder, Appliquer le plan, puis Vérifier (dry-run) : tu vois ce qui changerait avant d'agir.
Répare un hôte fantôme (l'erreur impossible). Si une appli pointe un hôte inexistant, ouvre la vue Applications, sélectionne-la : le <select> « Hôte » ne montre que des hôtes réels. Choisis le bon, Sauvegarder, Appliquer. Tu ne peux pas re-saisir le fantôme.
Bascule d'instance. Vue Réseau, bouton « Activer » sur une autre instance. Toutes les vues suivent, sans redémarrer.
Sens le garde-fou. Essaie de sauvegarder un plan incohérent (ex. une base dont le consommateur n'existe pas) : la console refuse avec une raison. L'invalide ne passe pas.
Casse & répare. Édite hosts.yml à la main, reviens dans la GUI, « Appliquer le plan » : ta modification est écrasée par le plan. La source de vérité, c'est le plan — pas l'inventaire.

Pour aller plus loin (dépôt)

Lancer : make inventaire-ui ; le code : scripts/inventory_gui.py.
Ce que le GUI sait écrire (et la preuve) : scripts/couverture_gui.py (P19).
Le flux plan → apply : unité Infra as Code & idempotence.
La flotte : unité Multi-instance & fédération.

8.2 KiB Raw Blame History Unescape Escape