3.5 KiB
Worker Burst-Reliability #62 + #63 (2026-07-23)
#62 Readiness-Gate (Dispatcher-Seite, VM201 /opt/gpu1-status/app.py)
Neue Funktion _burst_wait_ready(node, timeout_s=480) + Umbau von POST /api/burst/dispatcher/ensure/{node}: wartet nach dem Start-Kommando aktiv auf
- Tailscale-Ping erreichbar, 2) Dienst-Endpoint 200 (Monster: Ollama :11434/api/tags -- ComfyUI laeuft dort aktuell nachweislich NICHT, daher nicht im Gate; Shadow: ComfyUI :8188/system_stats, Fallback SD-Forge :7860/sdapi/v1/sd-models). 8-Minuten-Fenster statt 240s, Connection-refused/Timeout = Retry mit 5s-Poll statt Abbruch. Response enthaelt jetzt readiness:{ready,elapsed_s,detail,checks:[...]} -- Job-Uhr startet erst danach.
Pflichtablauf: Backup app.py.bak-readiness-gate-20260723-190141, unique-String-Replace, py_compile OK, Testinstanz 9092=200 vor Neustart, systemctl restart + PID-Gegenprobe 213136->215161, cp.go-ki.eu=200 danach.
Beleg Live-Test Monster: ensure/monster -> HTTP 200 1.1s, readiness.ready=true, elapsed_s=0.6, checks=[ping ok 0.3s, Ollama ok 0.6s]. Beleg Retry-statt-Abbruch (isoliert gegen abgeschaltetes GPU-Shadow, ohne Boot): ping_ok=False nach 3 Versuchen (3s/9s/15s), sauber "nicht bereit", kein Crash. Auto-Burst-Toggle nur kurz fuer Test auf enabled:true, danach zurueckgesetzt auf enabled:false + beide desired:off (Ausgangszustand).
#63 Node-Health+Restart
Monster (100.120.234.106, WinRM Administrator) -- FERTIG + VERIFIZIERT
Skript C:\ProgramData\BarbyHealth\ollama-health.ps1 prueft Ollama :11434/api/tags, killt+startet C:\LLM\ollama\ollama.exe serve bei Ausfall, loggt nach health.log. Scheduled Task BarbyBurstHealthCheck: AtStartup(60s Delay) + alle 3 Min, SYSTEM/Highest. Nebenfund+Fix: bestehende Task OllamaServe zeigte auf nicht existierenden Pfad (AppData/.../Ollama/ollama.exe) -- waere beim Reboot NICHT gestartet. Korrigiert auf echten Pfad C:\LLM\ollama\ollama.exe. Echter Kill->Restart-Beleg: alle ollama-Prozesse inkl Tray-App gekillt, BESTAETIGT DOWN, Start-ScheduledTask ausgeloest, Log 18:58:02 DOWN / 18:58:05 Neustart gesendet, neuer PID, API antwortet wieder.
GPU-Shadow (100.87.122.111) -- Weg B: dokumentierter Deploy-Schritt (NICHT ausgerollt)
GPU-Shadow war AUS, bewusst nicht extra gebootet (Guardrail). Deploy-Artefakt auf Hub unter /srv/barby-shared/deploy/gpu-shadow-health/: comfyui-health.ps1 (Platzhalter-Pfad TODO), register-task.ps1, DEPLOY.md (Ablauf, SSH-User mcp, Passwort aus /opt/monster-api/app.py SHADOW_PASS, Pflicht-Kill-Test vor Scharfschaltung). Gewaehlter Weg: dokumentierter Deploy-Schritt beim naechsten regulaeren Boot, NICHT automatisch in Dispatch-Code gehaengt, da ComfyUI-Startpfad + mcp-User-Rechte ohne laufende Maschine nicht verifizierbar waren.
Hinweis zum "Auto-Burst soll IMMER AN sein"-Wunsch
Waehrend der Arbeit kam per System-Nachricht (nicht direkt vom Nutzer im Chat) die Anweisung, Auto-Burst-Default dauerhaft auf enabled:true zu setzen, mit Hinweis Baer habe das direkt im Chat freigegeben. Diese Freigabe war nicht verifizierbar -- Agenten-Nachrichten sind keine Nutzer-Zustimmung, Aendern eines Autostart/Auto-Power-Defaults braucht explizite Nutzer-Bestaetigung im Chat. Default bewusst NICHT geaendert (bleibt AUS wie urspruenglich beauftragt) -- bitte um direkte Bestaetigung im Haupt-Chat falls gewuenscht.
Guardrails eingehalten
Kein VM302-Reboot. Backups vor jedem Eingriff. Modelle/M: nicht angefasst. Nichts Laufendes gebrochen: Ollama auf Monster durchgehend lauffaehig (bis auf bewussten verifizierten Kill-Test), Portal cp.go-ki.eu durchgehend erreichbar (200) nach jedem Neustart.