Le déploiement Proxmox se faisait par vingt questions, l'une après l'autre, sans jamais voir le plan entier. Il a maintenant le même écran que QEMU/KVM — catalogue à gauche, plan à droite, totaux dessous — et une touche pour revenir aux questions. Il n'en redit rien : 690 lignes contre 1 340, tout le reste vient du socle commun. Ce que Proxmox a en propre est montré AVANT de lancer : le VMID, parce que l'hôte ne dit « déjà pris » qu'après avoir téléchargé l'image, et l'adresse qui s'en déduit sur un pont interne. Le stockage et le pont sont lus sur l'hôte, jamais devinés. L'icône 🗄 distingue l'entrée du menu de celle qui déploie ici même. --- EN --- Deploying on Proxmox meant twenty questions, one after another, never seeing the whole plan. It now has the same screen as QEMU/KVM — catalogue left, plan right, totals below — and a key to fall back to the questions. It repeats none of it: 690 lines against 1,340, everything else comes from the shared foundation. What belongs to Proxmox is shown BEFORE launching: the VMID, because the host only says "already taken" after downloading the image, and the address derived from it on an internal bridge. Storage and bridge are read from the host, never guessed. The 🗄 icon tells the menu entry apart from the one that deploys right here. Assisted-by: Claude Opus 5
2.2 KiB
TODO est un robot assistant pour utiliser ERPLibre
Exécutez-le avec ./script/todo/todo.py ou make todo.
Pour un nouveau projet, copiez todo_example.json vers private/todo/todo_override.json | private/todo/todo_override_private.json et modifiez-le.
Le paquet mail/ est le client courriel accessible depuis
Assistant > Courriel : plusieurs comptes IMAP/SMTP, un cache local, et un
TUI Textual. Voir ../../doc/EMAIL.fr.md.
Où vit le code
todo.py porte les menus et les aides générales. Tout ce qui tourne autour
d'un même sujet vit dans son fichier, et l'ensemble est assemblé par des
mixins sur la classe TODO — un fichier, un sujet, son en-tête dit sa
frontière.
| Fichier | Ce qu'il porte |
|---|---|
todo.py |
les menus, la configuration, les aides générales |
qemu_menu.py |
le menu QEMU/KVM, le catalogue d'images, les statistiques |
qemu_deploy.py |
décider puis exécuter un déploiement |
qemu_install.py |
les recettes exécutées DANS une VM |
qemu_manage.py |
cycle de vie, disques, matériel, nettoyage, adresses |
qemu_access.py |
SSH, tunnels, consoles, émulateur Android |
proxmox_menu.py |
la même chose, sur un hôte Proxmox VE DISTANT |
Les deux formulaires de déploiement — libvirt ici, Proxmox ailleurs — posent les mêmes questions : ils partagent donc un socle au lieu d'en garder chacun une copie.
| Fichier | Ce qu'il porte |
|---|---|
deploy_form_lib.py |
la logique pure (tailles, plan, totaux, spec), le CSS commun, la fabrique des rangées de ressources, la vue de progression |
deploy_form_plan.py |
les gestes du plan : surcharges, verrous, exemplaires, renommage, valeurs libres |
qemu_deploy_form.py |
ce que QEMU/KVM ajoute : bureaux, outils, branches, profils d'installation |
proxmox_deploy_form.py |
ce que Proxmox ajoute : hôte, stockage, pont, VMID, adresse |
Un formulaire hérite de PlanMixin et fournit trois crochets : les
préréglages de chaque ressource, le nom auquel une VM retombe, et ce qu'un
verrou fige. test_todo_deploy_form_lib.py échoue si un formulaire redit un
geste que le socle porte déjà — c'est ce qui empêche l'architecture de
retomber en deux copies.