* feat(litellm): heartbeat anti-502 + request_timeout 20s
Cause racine du 502 « 1ʳᵉ demande après une pause » : la connexion keep-alive
LiteLLM↔llama-server devient inactive → llama-server la ferme → LiteLLM garde le
socket mort → la requête suivante part dans le vide → timeout → 502.
- llm-heartbeat : service systemd qui appelle hermes-default toutes les 15s
(max_tokens:1, /no_think → ~10ms GPU) → la connexion n'est jamais inactive,
jamais périmée. Logge les échecs → sert aussi de sonde (vraie génération).
- request_timeout 60→20s : un socket périmé échoue vite, dans la fenêtre où
num_retries:2 peut rejouer sur une connexion neuve (sinon le client abandonnait
avant le retry → 502 sec).
- Doc : admin/incidents-llm-gpu.md (fix racine) + README rôle.
⚠️ heartbeat appelle hermes-default en continu → si bascule sur Claude (facturé),
mettre llm_heartbeat_enabled: false. request_timeout global → remonter si Claude.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* feat(llama_server): watchdog auto-réparation du wedge ROCm
Service systemd local sur gpu-01 qui sonde une vraie génération sur :1234
(pas juste /health, qui ment quand le slot d'inférence est figé). Sur N
échecs consécutifs → systemctl restart llama-server en local (root, sans
SSH/sudo distant). Gère le 503 "Loading model" post-restart sans le compter
comme échec.
Complète le llm-heartbeat (rôle litellm) : le heartbeat empêche la péremption
par inactivité de la connexion ; le watchdog répare le figeage du serveur lui-même.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Cause du burst de 502 « cold-start » : après un restart de llama-server, LiteLLM
garde des connexions keep-alive mortes dans son pool → la requête suivante hang
jusqu'au timeout. Or request_timeout valait 600s → hang jusqu'à 10 min, sans log
(LiteLLM attendait encore). Fix :
- request_timeout 60s : borne le hang d'une connexion morte
- num_retries 2 : rejoue → évince le socket périmé, repart sur une connexion neuve
Doc : section dédiée dans admin/incidents-llm-gpu.md (mécanisme + application +
reste à faire = watchdog qui bounce llama-server ET litellm).
Application : ansible-playbook -i inventory.yml playbooks/storage-01.yml --tags litellm
(redémarre LiteLLM → applique le fix ET purge le pool d'un coup).
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Audit complet des rôles vs état réel du cluster. Chaque rôle a maintenant
un README.md : but, variables (défauts + surcharges host_vars/vault),
handlers, vérifications, caveats.
Gaps découverts et documentés :
- minio : rôle VIDE (tasks/main.yml sans aucune tâche), service inactif —
placeholder à implémenter ou retirer (ports 9000/9001 ouverts pour rien)
- llama_server : ne gère que l'instance GPU :1234 — les services CPU
llama-server-system :1236 et llama-server-monitor :1237 sont créés à la
main sur gpu-01, non reproductibles par make apply-gpu (+ un
llama-server-dev.service non documenté présent sur l'hôte)
- hermes_auto_improve : defaults port/repo/branch/log non consommés
(valeurs en dur dans les scripts), défaut branch obsolète
- lm_studio : README de dépréciation, candidat suppression
Tables admin/ops/ansible.md, README.md et CLAUDE.md corrigées en conséquence.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
LiteLLM écoutait sur 127.0.0.1 uniquement — les pods k8s (10.42.x.x)
ne pouvaient pas atteindre 192.168.10.1:4000, Open WebUI affichait
"Aucun modèle disponible". Binding changé en 0.0.0.0 + nftables ouvert
pour 192.168.10.0/24 et 10.42.0.0/16.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- check_k8s_pods : grep -c retournait "0\n0" (|| echo 0 inutile quand
grep-c affiche 0 même en cas d'absence de match) — utilise un cache
intermédiaire pods_output + running=$(grep -c) || running=0
- cmd_start : uncordon automatique si nœuds SchedulingDisabled détectés
(séquelle d'un funk-stop --k8s), suivi d'une attente pod infra avant
le check — évite de devoir passer --k8s juste pour débloquer le cluster
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Ajoute check_k8s_pods / check_k8s_workloads (argocd, infra, monitoring).
funk-start vérifie désormais les pods k8s si les nœuds sont joignables,
même sans --k8s. En mode --k8s : attente ArgoCD + infra avant le check.
funk-status montre aussi l'état des pods si cluster up.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
hermes-agent spawne des process Python qui survivent hors du cgroup
systemd après stop_service. Ils gardent des file descriptors ouverts sur
/srv/data (logs, state.db-shm) et bloquent le umount.
Ajout d'un lsof + kill -9 sur tous les process tenant /srv/data avant
sync + umount — garantit un démontage propre sans dépendre de systemd.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Avant, shutdown -h now était appelé directement après stop qdrant/postgresql.
systemd démontait /srv/data pendant la séquence d'extinction sans garantie
que tous les buffers aient été flushés.
Séquence ajoutée avant shutdown :
1. stop nfs-server (était oublié dans le script)
2. sync — flush tous les buffers disque
3. umount /srv/data — démontage explicite du RAID5
Si umount échoue, lsof affiche le processus bloquant avant d'abandonner.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Après funk-stop --k8s, les nœuds reviennent Ready mais SchedulingDisabled
(cordon stocké dans etcd). Sans uncordon, tous les pods restent Pending.
Ajouts dans funk-start --k8s :
- kubectl uncordon sur les nœuds SchedulingDisabled uniquement (idempotent)
- Attente ArgoCD Running (jusqu'à 3 min) — confirme que le GitOps est opérationnel
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Remplace le talosctl shutdown immédiat par une séquence en 6 étapes :
1. kubectl cordon tous les nœuds (empêche rescheduling)
2. kubectl drain compute-02/03 (SIGTERM pods, 30s grace, PVCs NFS libérés)
3. kubectl drain compute-01 (ArgoCD, system pods)
4. Vérification NFS : ss confirme plus de sessions :2049 actives
5. talosctl shutdown (halt propre, plus rien ne tourne)
6. Attente extinction ping
Prometheus et Grafana ont 30s pour flusher WAL/SQLite avant terminaison.
storage-01 (NFS server) est éteint en dernier une fois la vérification passée.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Nouveau rôle hermes_user : création user/group UID 1002 sur storage-01
et gpu-01, sudoers limités par host, clé SSH ed25519 générée sur
storage-01 et distribuée vers gpu-01, ssh_config + known_hosts
- Kubeconfig copié depuis ansible vers hermes sur storage-01
- ask-agent : script bash LiteLLM pour déléguer aux agents
system/monitor/brain/funk-ai
- hermes-skills/funk/agent-delegation : skill Hermes pour les
inter-profile calls avec pattern Terminal: ask-agent
- Playbooks storage-01 et gpu-01 : ajout du rôle hermes_user
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
