W44 Burst-Compute: A40-Einzelinstanz-Garde, Schritt 1 (2026-07-23)

Datei: /opt/gpu1-status/app.py (VM201, 100.114.24.89), Portal-Service gpu1-portal.service

Was gebaut wurde

Neues Modul-Level-Lock _A40_GUARD (threading.Lock, additiv, default aktiv) direkt nach KASM_VM/HUB_BRAIN-Konstanten (Zeile ~10636 vor Edit).
_a40_guard_try_acquire(job_label) / _a40_guard_release() — einfache Belegt/Frei-Semaphore.
Neuer Endpoint GET /api/burst/a40-guard/status (auth-gated wie alle anderen /api/*-Routen).
Erster geguardeter Call-Site: POST /api/hermes/generate/video (hermes_generate_video) — gibt bei belegter A40 sofort {"status":"busy",...} zurueck statt den Job durchzureichen; released im finally-Block auch bei Exception.

Warum nur dieser eine Endpoint (Schritt 1 von geplanten 4)

Kleinschrittig wie von Koordinator gefordert: erst EIN Call-Site guarden + verifizieren, dann in Folgeschritten CPU-Offload, Burst-Dispatcher, Portal-Toggle. Weitere Heavy-Endpoints (ACE-Step, ggf. weitere Wan2.2-Pfade) folgen in Schritt 2+, sobald dieser Baustein bestaetigt sauber laeuft.

Ablauf (Portal-Skill, vollstaendig durchlaufen)

Backup: /opt/gpu1-status/app.py.bak-w44-garde-20260723_175843 (md5 50fb440aa4ea55e0f49fbc42809e59d4)
Fresh-Read vor Edit: md5 von Backup == md5 der Live-Datei zum Zeitpunkt des Edits (kein Drift durch andere Worker)
Edit: reiner unique-String-Replace (kein Zeilennummern-Patch), zwei Anker (KASM_VM = "100.104.5.57"... und die komplette hermes_generate_video-Funktion), je assert count==1 vor dem Replace
python3 -m py_compile app.py → OK
Testinstanz Port 9092 (venv/bin/uvicorn app:app --port 9092) → GET / = 200, GET /api/burst/a40-guard/status = 401 (korrekt auth-gated, Route existiert), danach sauber gestoppt (fuser -k 9092/tcp)
Erste systemctl restart wurde durch einen 502-Gateway-Abbruch der SSH-Session unterbrochen — Prozess lief mit ALTER PID/altem Code weiter (Startzeit 16:10, vor dem Edit). Erkannt durch PID/Startzeit-Check, sofort korrigiert:
Sauberer systemctl restart gpu1-portal.service #2 → neue PID 195211, Startzeit 18:04:47 (nach dem Edit)
Verifiziert: GET http://127.0.0.1:9090/api/burst/a40-guard/status = 401 (Route jetzt live), GET / = 200
https://cp.go-ki.eu/ von aussen = 200

Sicherheitsaspekt der laufenden Arbeit

Der aktuell laufende Video-Build rendert direkt gegen ComfyUI :8188 (VM302), NICHT ueber app.py/hermes_generate_video. Der neue Guard betrifft ausschliesslich den :8190-Pfad (separates Video-Pipeline-Dashboard) und wurde durch die zwei systemctl restart NICHT unterbrochen — kein VM302-Reboot, kein Eingriff in den 8188-Prozess.

Lehre fuer die naechsten Schritte

Nach JEDEM systemctl restart MainPID + Startzeit gegenpruefen (systemctl show ... -p MainPID + ps -o lstart), nicht nur is-active — ein abgebrochener SSH-Call durch die 502-Flakiness des Hub-Gateways kann einen Restart-Befehl verschlucken, ohne dass is-active das anzeigt (alter Prozess ist ja noch aktiv).

3 KiB Raw Permalink Blame History