barby/hermes-erkenntnisse
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity
hermes-erkenntnisse/burst-compute/w44-a40-guard-step2-2026-07-23.md

3.3 KiB
Raw Permalink Blame History

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.