Proposition : VM de base VirtualBox prête à l'emploi pour l1

[cedric-ribier]

Contexte

En suivant les labs l1, l'installation manuelle (Python, uv, dsoxlab, pytest...) peut être un frein pour un vrai débutant. J'ai préparé une VM VirtualBox de base, prête à l'emploi, avec l'environnement déjà configuré.

Proposition

• Image OVA téléchargeable ici : https://github.com/cedric-ribier/linux-dsoxlab-training/releases/tag/v1.0-base-vm
• README détaillé ici : https://github.com/cedric-ribier/linux-dsoxlab-training/blob/add-base-vm-virtualbox/vm-images/vm-virtualbox/README.md
• Je peux aussi faire l'équivalent VMware si le format t'intéresse

Question ouverte

Préfères-tu que j'héberge l'image sur mon fork en continu, ou que tu la reprennes sur ton propre repo/release si tu valides l'approche ?

[stephrobert]

Idée validée, merci pour le travail et pour la patience.

Elle ne sera pas intégrée ici, mais dans dsoxlab : stephrobert/dsoxlab#91.

La raison est celle de l'architecture. L'image embarque le moteur et ses prérequis (Python, uv, dsoxlab, l'hyperviseur, Terraform, ansible-runner), pas des labs : elle est donc générique, au même titre que les templates Terraform et cloud-init déjà packagés dans dsoxlab. La rattacher au catalogue Linux la figerait sur un domaine, alors qu'elle rend le même service à terraform-training, ansible-training et aux suivants.

Corollaire, qui répond à votre question d'hébergement : les artefacts seront publiés sur les Releases de dsoxlab, avec SHA256SUMS et attestation de build, plutôt que sur un fork. Le projet publie déjà avec Trusted Publishing et provenance, et distribuer plusieurs gigaoctets sans preuve serait le maillon faible de cette chaîne.

Deux points que l'issue instruit et sur lesquels votre expérience de construction sera utile :

• La virtualisation imbriquée décide du périmètre. Une image VirtualBox ou VMware ne peut faire tourner les labs vm (KVM, Incus) que si l'hôte l'autorise, ce qui est faux dès qu'Hyper-V ou WSL2 tourne sur Windows, et impossible sur Mac Apple Silicon. Savoir si votre image sert déjà les labs vm ou seulement les labs shell trancherait la question.
• La construction doit être reproductible et versionnée (Packer en CI), sinon l'image n'est régénérable par personne et pourrit à la première mise à jour.

Si vous voulez porter la PR, elle est la bienvenue sur dsoxlab plutôt qu'ici. Sinon votre travail servira de point de départ documenté.

[cedric-ribier]

Merci pour la réponse détaillée et pour avoir ouvert dsoxlab#91 — la
logique architecturale se tient, une image générique au niveau du moteur
a plus de sens qu'un rattachement au catalogue Linux. Content que le SHA256SUMS

• attestation de build soit déjà dans les tuyaux, c'était mon inquiétude
  principale sur l'hébergement.

Pour répondre aux deux points :

Périmètre vm vs shell : à distinguer deux choses de mon côté.
L'image générique du moteur dsoxlab ne sert pour l'instant que les labs
shell. En revanche, sur mes VMs de travail (Debian en VM sous VMware
Fusion sur Mac), j'ai KVM et Incus fonctionnels en virtualisation
imbriquée — labs vm inclus, testé et validé récemment. Donc la chaîne
complète fonctionne dans mon setup, mais l'image "moteur" packagée elle-même
n'a pas encore été testée avec les labs vm.

Reproductibilité (Packer/CI) : je n'ai pas construit mon image avec
Packer pour l'instant — plutôt manuellement, ce qui confirme votre point :
ce n'est pas régénérable en l'état. J'avais envisagé un versionnement
incluant KVM/Incus tel quel, mais vu que vous demandez une construction
reproductible via Packer en CI, je pense plutôt explorer cette voie-là
de mon côté plutôt que de pousser ma version manuelle actuelle.

Autre argument en faveur de cette approche : le provisioning KVM casse à
chaque mise à jour de dsoxlab, à cause d'un bug non corrigé du provider
dmacvicar/libvirt en 0.9.x (os.firmware qui devient null après apply —
voir dmacvicar/terraform-provider-libvirt#1333, où j'ai documenté le
contournement). Le correctif est dans templates/terraform/kvm/main.tf,
donc réécrasé à chaque uv tool upgrade dsoxlab. Tant que ça reste un
patch local non versionné, ce n'est reproductible pour personne d'autre —
un argument de plus pour une build Packer figée plutôt qu'un simple
versionnement du contenu actuel.