Daniel Allaire 36b6926e21 patient 0 : il n existe plus, et le depot le disait encore au present

Ses machines sont detruites. Le depot en parlait comme d un ecosysteme vivant,
et l une de ces phrases datait de la veille : positionnement.md comptait ses
5 VM dans la flotte, chiffre que j avais moi-meme ecrit en revisant.

CE QUI EST CORRIGE

positionnement.md         51 VM sur quatre plans vivants, et non 56 sur cinq
sortir-les-cles-du-poste  le genome est replique DEUX fois, non trois
wiki/Glossaire.md         SQLite : ce qu il PORTAIT
filiation-emancipation    la famille de pairs a perdu un pair
decisions-architecture    D-83 consigne le retrait, avec son cout
carte-set-ops.md          80 decisions en vigueur

LE COUT, PARCE QU IL N ETAIT NOMME NULLE PART

D-82 lui avait laisse deux raisons d etre : la mise en oeuvre de reference du
modele origine, et un TEMOIN de plus du genome. Le retrait solde la premiere et
abaisse la seconde de trois copies vivantes a deux.

Or c est le raisonnement de son propre README qui portait tout : on n echappe
pas a la boucle par la ruse, mais par le NOMBRE. Le nombre a baisse. Et le point
unique de defaillance que patient 0 existait pour eliminer — eregion, hors
flotte, que Set-OPS ne deploie ni ne sauvegarde ni ne prouve — est toujours a la
racine. Il n a jamais ete elimine, seulement promu ; il n y a maintenant plus de
miroir independant pour l absorber.

CE QUI RESTE SUR LE TERRAIN, ET QUI N EST PAS DE LA PROSE

Son plan est encore sur disque en federe: true. La federation lui reserve donc
toujours l index 29, la zone SDN t29, ses VNets, les VLAN 1291-1296 et les
sous-reseaux 10.29.16-21.0/24. Quatre machines du site — backup, cache, dns,
forge — acceptent encore SSH, apt, DNS et HTTPS depuis 10.29.0.0/16 : un
perimetre vide. Le runner du site clone encore ops-patient0.

C est un geste, pas une intention, et il touche le reseau : il n est pas fait
ici. La sequence est listee dans D-83.

make prouver --verifier : CONFORME, 56 OK, 0 echec, 1 saute.

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

2026-09-07 00:13:21 -04:00

5.7 KiB

Raw Blame History

Positionnement : ce que Set-OPS fait maison, et quand adopter l'existant

Pour qui : le mainteneur, et quiconque arbitre une évolution : ce qui reste maison, et à quel seuil on adopte l'existant.

Ce document acte une décision pour ne plus la redébattre à chaque évolution : quelles parties de Set-OPS sont volontairement maison, pourquoi, et à partir de quel seuil il vaudra mieux adopter un outil du marché plutôt que continuer à le réimplémenter.

En une phrase : le cœur de Set-OPS (un plan déclaratif qui génère l'inventaire Ansible) existe déjà sous forme mûre — c'est NetBox. Set-OPS en est une version souveraine, légère et sur-mesure, assumée comme telle. Le risque à surveiller est de réimplémenter NetBox/AWX brique par brique.

1. La carte : chaque facette a un équivalent du marché

Facette de Set-OPS	Équivalent mûr	Remarque
Source de vérité déclarative → génère l'inventaire Ansible	NetBox / Nautobot + plugin `netbox.netbox.nb_inventory`	Le plus proche du cœur de Set-OPS (le « plan »).
GUI qui exécute Ansible (déployer, RBAC, planification)	AWX / Ansible Automation Platform ; Semaphore	Set-OPS a un GUI plus modeste (lancer `make`).
« La définition instancie toute la flotte »	NixOS + Colmena/morph ; Terraform (provider Proxmox) pour créer les VM	L'idée « méta-classe » au sens littéral.
Application = entité pivot avec ses dépendances et ressources	Backstage (catalogue de composants + graphe)	Le modèle `requiert`/`utilise`/`expose` y ressemble fortement.
IPAM / dérivation d'adressage	NetBox (IPAM natif)	Set-OPS dérive depuis la nomenclature.

Aucun produit ne fait l'assemblage exact : Proxmox + Ansible + le modèle bespoke (DSN, exposition DNS, dérivation par fonction) en un seul outil souverain et léger. Cet assemblage-là est propre à Set-OPS.

2. Ce que Set-OPS fait sciemment maison (et pourquoi)

Le plan déclaratif (instance/plan/serveurs.yml, applications.yml, bases-donnees.yml, domaines.yml, nomenclature.yml) et le générateur d'inventaire (make instancier).
Le modèle application-hub : bindings DSN (portée application/groupe/hôte) et exposition DNS, taillés exactement pour nos concepts.
Le GUI (Python stdlib, fichier unique) et les validateurs / garde-fous (diff-vide, node --check, vérificateurs de registres).

Raisons assumées :

Souveraineté — mission explicite du dépôt. NetBox + AWX + Backstage = trois applications lourdes à héberger et maintenir (Django + PostgreSQL, etc.). Set-OPS reste possédé en entier, sans dépendance.
Bon dimensionnement — mais l'argument a bougé, et il faut le dire honnêtement. Ce document a longtemps écrit « ~13 VM ». Le moteur pilote aujourd'hui quatre plans vivants (mesuré le 2026-09-06) : Chezlepro 14 VM, Technolibre 15, le lab 15, plus les 7 machines du site — 51 VM déclarées, réparties sur des écosystèmes qui ne se parlent pas. (Patient 0 en portait 5 ; ses machines n'existent plus.) Ça reste très loin de l'échelle entreprise pour laquelle NetBox est fait, et le seuil du §4 n'est pas franchi. Mais la courbe monte : c'est le chiffre à regarder quand on se demande si la décision tient encore.
Modèle sur-mesure — NetBox exprimerait nos DSN / expositions à coups de custom fields et de plugins, moins naturellement que nos registres.
Maîtrise — chaque ligne est comprise et auditable.

3. Ce que le maison NE fait PAS (et que les outils mûrs ont)

À garder en tête honnêtement — ce sont des fonctions qu'on n'a pas, pas des bugs :

historique/audit des changements (au-delà de git) ;
RBAC multi-utilisateurs ;
détection de conflits IPAM, réservations, gestion d'adresses à grande échelle ;
webhooks / intégrations tierces, API riche (REST/GraphQL) ;
écosystème de plugins, communauté, correctifs de sécurité maintenus par d'autres.

4. La règle : plan de contrôle gelé en fonctionnalités

Set-OPS continue d'évoluer pour décrire et déployer l'écosystème (rôles, services, registres applicatifs). En revanche, le plan de contrôle (le GUI, le générateur, l'IPAM, la modélisation) est considéré gelé en périmètre : on ne lui ajoute pas de fonctionnalités de type NetBox/AWX.

Seuils d'adoption (les signaux de bascule)

Adopter l'outil du marché — sans réécrire, en branchant Ansible/notre GUI par-dessus — dès qu'un de ces besoins devient réel :

Besoin qui apparaît	Adopter
RBAC, plusieurs opérateurs, historique d'audit, secrets/credentials centralisés	AWX (exécution)
IPAM sérieux, détection de conflits, source de vérité partagée, API/webhooks	NetBox (et `nb_inventory` remplace notre générateur)
Catalogue de services / portail développeur, ownership, scaffolding	Backstage
Provisionnement de VM déclaratif et reproductible à plus grande échelle	Terraform (Proxmox) ou NixOS + Colmena

Test simple : si on se surprend à vouloir réimplémenter une de ces fonctions dans Set-OPS, c'est le signal d'adopter l'outil correspondant plutôt que de prolonger le maison.

5. Décision en vigueur

On garde le plan de contrôle maison : il fonctionne, il est souverain et bien dimensionné pour aujourd'hui. Pas de réécriture sur NetBox « par principe ».
On gèle son périmètre fonctionnel (voir §4).
On réévalue à l'échéance d'un seuil ci-dessus, ou si la charge de maintenance du maison dépasse le coût d'héberger l'outil mûr.

5.7 KiB Raw Blame History