Skip to content

feat(doctor): contrôler le pool de stockage Incus (0.1.84) - #193

Merged
stephrobert merged 2 commits into
mainfrom
fix/incus-remediation-init
Aug 24, 2026
Merged

feat(doctor): contrôler le pool de stockage Incus (0.1.84)#193
stephrobert merged 2 commits into
mainfrom
fix/incus-remediation-init

Conversation

@stephrobert

Copy link
Copy Markdown
Owner

Summary

Un utilisateur a signalé sur
linux-dsoxlab-training#54
que sur un provisionnement Incus raté faute d'avoir joué
incus admin init --auto, seules les résolutions liées à KVM lui étaient
proposées.

Le symptôme avait raison, l'hypothèse évidente avait tort

_check_incus propose bien incus admin init — je l'avais écrit ailleurs à
tort, avant de lire le code. Mais il ne le propose que lorsque incus list
échoue en le disant.

Or incus list réussit sur une installation jamais initialisée : elle rend
simplement une liste vide. Le contrôle passait donc au vert, et la branche Incus
de collect_checks n'ajoutait que l'outil ISO — là où la branche KVM contrôle
son pool de stockage depuis longtemps. C'est cette asymétrie qui produisait la
phrase de l'utilisateur.

Le template le confirme : il crée le réseau
(resource "incus_network" "lab") mais écrit pool = "default" en dur dans
chaque volume, sans jamais le créer.

Le contrôle ajouté

Pendant exact de _check_libvirt_pool, avec ses trois états :

Situation Verdict
pool default présent ok
pool absent failed, remédiation sudo incus admin init --auto
incus storage list muet unknown, aucune remédiation

Le troisième compte : proposer une initialisation sur une machine dont on ignore
l'état réinitialiserait peut-être une installation qui fonctionne.

Un test vérifie que le template continue de supposer le pool sans le créer.
Le jour où Terraform le créera, ce test échouera — et personne n'aura à se
souvenir que ce diagnostic existait pour cette raison.

Sur le numéro de version

J'avais proposé 0.2.0 ; l'auteur a tranché pour 0.1.84, et c'est le bon
choix : ce contrôle est un ajout de diagnostic qui ne change ni contrat, ni
commande, ni sortie existante. Les entrées 0.1.75 à 0.1.83 restent chacune sous
son propre numéro, en accord avec les tags déjà publiés.

Type of change

  • Bug fix
  • New feature
  • Refactor
  • Documentation
  • Chore / tooling
  • Security / supply chain

Checklist

Always

  • uv run ruff check src/dsoxlab tests tests_e2e fuzz scripts passes
  • uv run mypy src/dsoxlab passes (strict)
  • uv run pytest passes — 861 passed, dont 7 neufs, éprouvés par deux mutations (contrôle décâblé → 1 rouge ; pool absent redevenu vert → 2 rouges)
  • uv run pytest tests_e2e passes — 18 passed
  • The engine stays domain-agnostic — le contrôle porte sur un provider packagé, jamais sur un domaine de labs
  • No hardcoded personal path or host; pathlib.Path throughout
  • Manually tested — joué sur linux-dsoxlab-training avec DSOXLAB_PROVIDER=incus : incus_pool apparaît à côté de incus et iso_tool, et un dépôt KVM ne le voit pas

When behavior changes

  • Both CHANGELOG.md and CHANGELOG.fr.md updated
  • Version bumped (0.1.83 → 0.1.84) and uv.lock refreshed

When a command or option is added, removed or changed

  • Keys added to both i18n/strings/en.py and i18n/strings/fr.py (3 clés), garde-fou i18n vert
  • Aucune commande ni option ajoutée — doctor gagne un contrôle : fullhelp reste exact
  • Checked with DSOXLAB_LANG=en and DSOXLAB_LANG=fr

When .github/workflows/ is touched

N/A — aucun fichier de .github/workflows/ n'est touché.

When the declarative contract (meta.yml / lab.yaml) changes

N/A — le contrat est inchangé.

Related issues

Closes stephrobert/linux-dsoxlab-training#54

🤖 Generated with Claude Code

stephrobert and others added 2 commits August 24, 2026 21:54
Un utilisateur a signalé, sur linux-dsoxlab-training#54, que sur un
provisionnement Incus raté faute d'avoir joué « incus admin init --auto », seules
les résolutions liées à KVM lui étaient proposées.

Le symptôme avait raison, et l'hypothèse la plus évidente avait tort.
_check_incus PROPOSE bien « incus admin init » — je l'avais écrit ailleurs, à
tort, avant de lire le code. Il ne le propose que lorsque « incus list » échoue
en le disant. Or « incus list » RÉUSSIT sur une installation jamais
initialisée : elle rend simplement une liste vide. Le contrôle passait donc au
vert, et la branche Incus de collect_checks n'ajoutait que l'outil ISO, là où la
branche KVM contrôle son pool de stockage depuis longtemps. C'est cette
asymétrie qui produisait la phrase de l'utilisateur.

Le template incus crée le réseau mais suppose le pool : il écrit
« pool = "default" » en dur dans chaque volume, sans jamais le créer. Sans
« incus admin init », provision échoue donc, et rien ne l'annonçait.

Le contrôle ajouté est le pendant exact de _check_libvirt_pool, avec ses trois
états : pool présent, pool absent avec la remédiation, et sonde muette qui ne
tranche pas — proposer une initialisation sur une machine dont on ignore l'état
réinitialiserait peut-être une installation qui fonctionne.

Un test vérifie que le template continue de supposer le pool sans le créer : le
jour où Terraform le créera, ce test échouera et personne n'aura à se souvenir
que ce diagnostic existait pour cette raison.

Cette version rassemble les neuf changements 0.1.75 → 0.1.83 et clôt l'audit des
angles morts : onze issues dont le fil commun était un seul défaut, un contrôle
qui concluait au vert faute de pouvoir mesurer. Deux comportements sont
délibérément renversés — une fixture qui manque fait désormais échouer run, un
lab dont le moteur est injoignable n'est plus dit prêt — ce qui fait de cette
version une mineure plutôt qu'un dixième correctif.

Vérifié : 861 tests dont 7 neufs, éprouvés par deux mutations, 18 e2e, ruff,
mypy strict, et le contrôle joué sur linux-dsoxlab-training avec le provider
incus, où il apparaît à côté de incus et iso_tool.

Closes stephrobert/linux-dsoxlab-training#54

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le numéro mineur était une proposition de ma part, pas une décision de l'auteur.
Le contrôle du pool Incus est un ajout de diagnostic : il ne change aucun
contrat, aucune commande et aucune sortie existante. Un correctif suffit.

Les entrées 0.1.75 à 0.1.83 restent où elles sont, chacune sous son propre
numéro : les rassembler sous une version qui n'existe pas aurait rendu le
CHANGELOG faux vis-à-vis des tags déjà publiés.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@stephrobert
stephrobert merged commit 486b3f4 into main Aug 24, 2026
19 checks passed
@stephrobert
stephrobert deleted the fix/incus-remediation-init branch August 24, 2026 20:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Erreur lors du provision avec incus

1 participant