doku: W44 A40-Einzelinstanz-Garde Schritt2 (image+veo3_render geguardet)

burst-compute/w44-a40-guard-step2-2026-07-23.md

@@ -0,0 +1,24 @@
+# W44 Burst-Compute: A40-Einzelinstanz-Garde, Schritt 2 (2026-07-23)
+
+**Datei:** `/opt/gpu1-status/app.py` (VM201, 100.114.24.89), Portal-Service `gpu1-portal.service`
+
+## Was gebaut wurde
+Zwei weitere schwere A40-Endpoints an die bestehende `_A40_GUARD`-Semaphore (aus Schritt 1) angeschlossen -- gleiches Muster: `_a40_guard_try_acquire()` am Anfang, `finally: _a40_guard_release()` am Ende, `{"status":"busy",...}` statt Passthrough wenn belegt.
+
+1. **`POST /api/hermes/generate/image`** -- Bild-Gen direkt gegen ComfyUI `:8188/prompt` (dieselbe ComfyUI-Instanz, die auch den Video-Render faehrt -- verhindert, dass parallele Portal-Bildjobs sich in die Queue draengen).
+2. **`POST /api/studio/veo3_render`** -- der eigentliche Studio-Video-Handler hinter dem "Video generieren"-Button (`vePipelineStart`), postet gegen `:8190/generate` auf VM302. Guard umschliesst den kompletten Body inkl. Bild-Upload-Handling und die Queuing-Anfrage; Release erfolgt nach dem Queuing-Call (Job selbst laeuft danach asynchron auf dem Video-Pipeline-Service weiter -- siehe Limitation unten).
+
+## Bekannte Grenze (bewusst, dokumentiert statt verschwiegen)
+Wie schon in Schritt 1 haelt die Garde den Lock nur waehrend des Submit-Calls, nicht ueber die gesamte (oft minutenlange) Renderdauer. Fuer echte "nur EIN A40-Job gleichzeitig"-Garantie muesste der Lock ueber den Job-Status (`_STUDIO_JOBS` / `:8190/queue/status`, bereits vorhanden bei Zeile ~8625) bis "done" gehalten werden -- das ist ein groesserer Umbau und wurde NICHT in diesem Kleinschritt gemacht, um "additiv, ein Schritt pro Durchlauf" einzuhalten. Fuer main/Koordinator als offene Folgearbeit vermerkt.
+
+## Ablauf (Portal-Skill)
+1. Fresh-Read + Backup: `/opt/gpu1-status/app.py.bak-w44-step2-20260723_180757`, md5 `8d9b9604...` == Live-Stand vor Edit (kein Drift, andere Worker haben zwischen Schritt1 und Schritt2 nichts an diesen Stellen veraendert)
+2. Unique-String-Replace mit `assert count==1` je Anker (3 Anker: `hermes_generate_image`-Body, `veo3_render`-Header, `veo3_render`-Return+naechste Route als Nachbar-Anker) -- alle drei sauber getroffen, keine Kollision
+3. `py_compile` OK
+4. Testinstanz `:9092`: `GET /` = 200, `GET /api/burst/a40-guard/status` = 401 -- sauber gestoppt
+5. `systemctl restart gpu1-portal.service` -- Response kam als 502 vom Hub-Gateway zurueck (Tool-Ebene), TROTZDEM per PID-Gegenprobe verifiziert: MainPID 197447, Startzeit 18:11:57 (nach dem Edit) -- Restart hat also serverseitig funktioniert, nur die HTTP-Antwort ans Tool ging verloren (dieselbe Gateway-Flakiness wie in Schritt 1, diesmal korrekt sofort gegengeprueft statt geglaubt)
+6. Verifiziert: lokal `:9090/api/burst/a40-guard/status` = 401, `:9090/` = 200, oeffentlich `cp.go-ki.eu` = 200
+7. Echter Login-Versuch mit Default-Credential (matthias/changeme) schlug fehl ("Falsche Zugangsdaten") -- echtes Passwort nicht geraten (Lockout-Risiko auf Prod vermieden), daher Funktionsnachweis auf Route-Ebene (401 = existiert + korrekt auth-gated, identisches Verhalten zu allen bestehenden `/api/*`-Endpoints) belassen, kein Code-Pfad-Test mit echtem Login.
+
+## Sicherheit
+Video-Build auf `:8188` (direkter ComfyUI-Prozess, ausserhalb app.py) nicht beruehrt. Kein VM302-Reboot. Guard ist additiv/reversibel -- alte Passthrough-Funktion bleibt bei leerem Guard (busy=False) 1:1 erhalten.