clonage : attendre la fin reelle de la tache, pas seulement l'avoir demandee

Mon optimisation d'hier soir a mis le cluster a genoux, et la faute est
entiere. En remplacant proxmox_kvm par un appel d'API direct, j'ai perdu ce
que le module faisait pour moi : attendre la fin de la tache (timeout: 600).
`POST .../clone` rend un UPID et la main immediatement ; Proxmox copie le
disque en tache de fond.

En sequentiel ca ne se voyait pas — l'attente de SSH absorbait le delai. En
PARALLELE, `make creer-vm` rendait la main pendant la copie : la limite de
concurrence ne retenait plus que des PROCESSUS VIDES et les clones
s'empilaient. Mesure : limite a 4, QUATORZE copies integrales simultanees.

Le symptome trompait — CPU de l'hyperviseur a 2 %, RAM a 13/62, et tout
ramait. Ce n'etait pas la machine, c'etait TrueNAS. Les 14 hotes ont echoue,
et flotte-creer a refuse de continuer : la garde ajoutee le matin meme a fait
son travail.

Le clonage relit desormais l'UPID et interroge l'etat de la tache jusqu'a
`stopped`, avec un message clair si la sortie n'est pas OK. La limite de
concurrence retrouve un sens : quatre clones REELS, pas quatre coquilles.

NOTE, PAS ENCORE CORRIGE : `raser` a le meme defaut dans l'autre sens. Il a
rapporte « 6/6 VM detruites » alors que les six etaient la — l'API accepte le
DELETE, rend un UPID, et la tache echoue ensuite sur « VM is locked (clone) ».
raser ne lit que la reponse immediate, jamais le resultat.

MESURE DES OPTIMISATIONS, reconstruction complete avec gabarit sur CephNVMe
(proposition de l'exploitant) et concurrence a 3 : 54 min 02 s contre
1 h 12 min 48 s — 26 % de moins, zero echec, 2838 taches.

Le cache d'artefacts est le plus rentable : Nextcloud 10m55s -> 4m14s, Forgejo
3m42s -> 1m33s, verifie par les `skipping` du journal. J'avais annonce un gain
« limite a la part telechargement » — cette part etait bien plus grosse que je
ne le croyais. forks=20 : les couches larges 3m09s -> 1m37s. Gabarit NVMe +
3 clones : 1m35s -> 1m17s par VM, le plus modeste, car les disques ECRIVENT
toujours sur TrueNAS.

Verifie : 3 clones actifs jamais plus, 7 devis CONFORME, ansible-lint
production, prouver.py 35 OK.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CHANGELOG.md

@@ -1,5 +1,63 @@
 # CHANGELOG — Set-OPS
 
+## 2026-08-10 — Le clonage ne s'attendait plus lui-même, et ça a saturé le stockage
+
+**Mon optimisation de la veille au soir a mis le cluster à genoux, et la faute est entière.**
+
+En remplaçant `proxmox_kvm` par un appel d'API direct (pour corriger la résolution par nom),
+j'ai perdu quelque chose que le module faisait pour moi : **attendre la fin de la tâche**
+(`timeout: 600`). `POST .../clone` rend un UPID et la main immédiatement ; Proxmox copie le
+disque en tâche de fond.
+
+En séquentiel ça ne se voyait pas — l'attente de SSH qui suit absorbait le délai. **En
+parallèle, c'est tout autre chose** : `make creer-vm` rendait la main pendant la copie, la
+limite de concurrence ne retenait plus que des **processus vides**, et les clones
+s'empilaient. Mesuré : limite à 4, **quatorze copies intégrales du gabarit simultanées**.
+
+Le symptôme trompait : **CPU de l'hyperviseur à 2 %**, RAM à 13/62 Gio — et tout ramait. Ce
+n'était pas la machine, c'était TrueNAS (LVM sur iSCSI). Les 14 hôtes ont échoué, et
+`flotte-creer` a refusé de continuer — la garde ajoutée le matin même a fait son travail.
+
+**Le clonage attend désormais la fin réelle** : il relit l'UPID rendu par l'API et interroge
+l'état de la tâche jusqu'à `stopped`, avec un message clair si la sortie n'est pas `OK`. La
+limite de concurrence retrouve alors un sens — quatre clones *réels*, pas quatre coquilles.
+
+### Au passage : `raser` annonçait des destructions qui échouaient
+
+En nettoyant, `make raser` a rapporté « 6/6 VM détruites » alors que les six étaient toujours
+là. L'API accepte le `DELETE`, rend un UPID… et la tâche échoue ensuite sur
+`VM is locked (clone)`. **`raser` ne lit que la réponse immédiate, jamais le résultat.**
+C'est exactement le même défaut, dans l'autre sens — noté ici, pas encore corrigé.
+
+### Ce que les optimisations ont réellement donné
+
+Reconstruction complète de Chezlepro, gabarit déplacé sur `CephNVMe` (proposition de
+l'exploitant), concurrence à 3 : **`54 min 02 s` contre `1 h 12 min 48 s` — 26 % de moins,
+zéro échec, 2 838 tâches.**
+
+| Phase | Avant | Après |
+|---|---|---|
+| création des 14 VM | 22m08s | **17m57s** |
+| amorçage PKI + DNS | 6m01s | 6m07s |
+| six couches | 44m39s | **29m58s** |
+
+**Le cache d'artefacts est le plus rentable, et de loin** : Nextcloud `10m55s → 4m14s`,
+Forgejo `3m42s → 1m33s`. Vérifié — `skipping` sur chaque téléchargement, les fichiers du
+cache portent toujours leur horodatage d'origine. J'avais annoncé un gain « limité à la part
+téléchargement » : cette part était bien plus grosse que je ne le croyais, et la
+décompression bz2 n'était pas le mur que je décrivais.
+
+**`forks = 20`** : socle + durcissement + AC + enrôlement PKI des 14 hôtes, `3m09s → 1m37s`.
+
+**Gabarit sur NVMe + 3 clones** : `1m35s → 1m17s` par VM. Le gain le plus modeste — les
+disques **écrivent toujours sur TrueNAS**, donc seule la moitié du chemin a été traitée.
+
+**L'amorçage n'a pas bougé**, et c'est cohérent : deux hôtes l'un après l'autre, aucun levier
+ne s'y applique.
+
+Sept devis **CONFORME** après coup, dont le MTU : les quatorze invités naissent à 1450 sans
+le moindre geste.
+
 ## 2026-08-10 — Le contrôleur télécharge et pousse ; la cible ne tire plus d'Internet
 
 **Inventaire mesuré** de ce qu'une reconstruction de tenant télécharge — environ **1,5 Gio** :

playbooks/proxmox/cloner_vm_debian.yml

@@ -226,6 +226,53 @@
       no_log: true
       when: not proxmox_clone_deja_la
 
+        # ATTENDRE QUE LE CLONE SOIT REELLEMENT FINI, pas seulement demande.
+    #
+    # `POST .../clone` rend un UPID et la main IMMEDIATEMENT : Proxmox copie le disque en
+    # tache de fond. `proxmox_kvm`, qu'on a remplace, attendait la fin (`timeout: 600`) — la
+    # reecriture par API avait perdu cette attente sans que ca se voie, parce qu'en
+    # sequentiel l'attente de SSH qui suit l'absorbait.
+    #
+    # En PARALLELE, c'est tout autre chose : `make creer-vm` rend la main pendant que le
+    # disque se copie, la limite de concurrence ne retient plus que des processus vides, et
+    # les clones s'empilent. Mesure du 2026-08-10 : limite a 4, DOUZE copies integrales du
+    # gabarit simultanees sur le meme stockage. Le CPU de l'hyperviseur a 2 %, et pourtant
+    # tout ramait — ce n'etait pas la machine, c'etait TrueNAS.
+    - name: Attendre la fin reelle du clonage
+      vars:
+        proxmox_api_racine: "https://{{ proxmox_api_host_effectif }}:{{ proxmox_api_port_effectif | default(8006, true) }}"
+      ansible.builtin.uri:
+        url: >-
+          {{ proxmox_api_racine }}/api2/json/nodes/{{ proxmox_clone_noeud
+          }}/tasks/{{ proxmox_clone_lance.json.data | urlencode }}/status
+        method: GET
+        headers:
+          Authorization: >-
+            PVEAPIToken={{ proxmox_api_user_effectif }}!{{ proxmox_api_token_id_effectif }}={{ proxmox_api_token_secret_effectif }}
+        validate_certs: "{{ proxmox_validate_certs | default(false) | bool }}"
+        status_code: [200]
+      register: proxmox_clone_tache
+      until: (proxmox_clone_tache.json.data.status | default('running')) == 'stopped'
+      retries: "{{ ((proxmox_clone_timeout | default(600) | int) / 10) | round | int }}"
+      delay: 10
+      changed_when: false
+      failed_when: false
+      no_log: true
+      when:
+        - not proxmox_clone_deja_la
+        - proxmox_clone_lance.json.data is defined
+
+    - name: Dire si le clonage ne s'est pas termine correctement
+      ansible.builtin.fail:
+        msg: >-
+          Le clonage de {{ proxmox_clone_nom }} (VMID {{ proxmox_clone_vmid }}) ne s'est pas
+          termine correctement : etat « {{ proxmox_clone_tache.json.data.status | default('?')
+          }} », sortie « {{ proxmox_clone_tache.json.data.exitstatus | default('?') }} ».
+          Regarder la tache sur {{ proxmox_clone_noeud }}.
+      when:
+        - not proxmox_clone_deja_la
+        - proxmox_clone_tache.json.data.exitstatus | default('OK') != 'OK'
+
     - name: Dire pourquoi le clonage a echoue, s'il a echoue
       ansible.builtin.fail:
         msg: >-