From 43372537974ac6152b3df71312e8a56d4a8abd4c Mon Sep 17 00:00:00 2001 From: Hitonabi Date: Fri, 28 Aug 2026 09:37:23 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20SAVEPOINT=20v4.0-beta=20=E2=80=94=20V2-?= =?UTF-8?q?0=20bis=20V2-3=20stehen,=20Laufwerk=20fehlt=20an=20der=20VM?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Vier Etappen gebaut und deployt, Polling ist weg (121 Anfragen/min je Tab -> ~2 einmalige Abrufe), SSE-Strom live belegt. Wichtig fuer die naechste Sitzung: Das optische Laufwerk haengt NICHT mehr an der VM. Rippy laeuft als reine Komprimier-Maschine. Und der Vorfall, der das aufgedeckt hat, ist dokumentiert — ein devices:-Eintrag in compose ist eine Startbedingung, und die hat api, worker und ui stillgelegt. Co-Authored-By: Claude Opus 5 --- SAVEPOINT.md | 91 +++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 90 insertions(+), 1 deletion(-) diff --git a/SAVEPOINT.md b/SAVEPOINT.md index c306eb8..de7c6c1 100644 --- a/SAVEPOINT.md +++ b/SAVEPOINT.md @@ -1,6 +1,95 @@ # SAVEPOINT — Rippy -## Aktueller Stand: v4.0-alpha — Rippy v2 beginnt, Etappe V2-0 steht (28.08.2026) +## Aktueller Stand: v4.0-beta — V2-0 bis V2-3 stehen, Polling ist weg (28.08.2026) + +> **Vier Etappen gebaut, alle gruen, alles deployt.** Und ein Vorfall, den es +> ohne den Deploy nie gegeben haette — der aber eine echte Altlast aufgedeckt hat. + +### ZUSTAND, gemessen + +| | | +|---|---| +| Repo | `05ab655` auf `main` | +| VM | **deployt und laufend** — alle 5 Container up, UI 200, API 200 | +| Tests | **378 gruen** + 3 uebersprungen (Sitzungsbeginn: 301) | +| Ereignis-Waechter live | `gesund: true`, `alter_sekunden: 0.8` | +| SSE-Strom live | `event: snapshot` mit vollem Job-Datensatz belegt | +| Doppelte Module | **0** (Sitzungsbeginn: 6) | +| UI-Taktgeber | **7 von 9 weg** — 121 Anfragen/min je Tab -> ~2 einmalige Abrufe | + +### ⚠️ DAS OPTISCHE LAUFWERK HAENGT NICHT MEHR AN DER VM + +`ls /dev/sr*` findet nichts, `lsscsi` ist leer. Rippy laeuft deshalb gerade als +**reine Komprimier-Maschine** — das ist ein vorgesehener Betriebsfall, aber +rippen kann sie so nicht. Wieder anstecken (Proxmox-USB-Passthrough), dann: + + ./deploy/geraete-override.sh && docker compose -p rippy up -d + +### DER VORFALL: ein fehlendes Laufwerk legte ALLES stumm + +Der Deploy von V2-3 brach mit: + + Error response from daemon: error gathering device information while + adding custom device "/dev/sr0": no such file or directory + +Danach waren api, worker UND ui unten; nur postgres und redis liefen. Ein +`devices:`-Eintrag in compose ist eine **Startbedingung** — und keiner der drei +Container braucht zum STARTEN ein Laufwerk. + +**Der Widerspruch war aelter als der Vorfall:** `install.sh` sagt bei fehlendem +Laufwerk ausdruecklich *„laeuft trotzdem durch, dann ist das eine reine +KOMPRIMIER-Maschine"* — `docker-compose.yml` sah das anders. Jeder Deploy nach +einem Abstecken haette das ausgeloest. + +**Behoben an der Ursache:** `devices:` ist aus `docker-compose.yml` raus. +`deploy/geraete-override.sh` ermittelt die Knoten dieses Hosts (sr + passender +sg ueber die SCSI-Adresse in /sys abgeglichen, Logik aus install.sh uebernommen) +und schreibt `docker-compose.override.yml` — die zieht Compose von allein dazu. +Das Skript schreibt die Datei **auch dann, wenn kein Laufwerk da ist**; sonst +bliebe eine alte Override mit /dev/sr0 liegen und der Fehler waere derselbe, nur +schwerer zu finden (die Datei ist gitignored, taucht also in keinem Diff auf). +`deploy.sh` ruft es vor dem Start auf. + +### Gebaut in dieser Sitzung + +- **V2-0** Monorepo: drei Zwillingsdateien zusammengefuehrt +- **V2-1** die vier Ports, ein Store (db.py x2 -> rippy/store), ein + Laufwerks-Treiber (der Auswurf lag zweimal da, mit VERSCHIEDENEN Vertraegen) +- **V2-2** SQLite hinter demselben Port, Auftrags-Queue mit Lease + (ersetzt die Zombie-Jagd), Konfigurationsschicht mit einer Praezedenz +- **V2-3** Ereignis-Bus, SSE-Endpunkt `/events`, Waechter als Bruecke zum + Worker, UI auf den Strom umgestellt + +### Vier Fehler, die unterwegs gefunden wurden + +1. **`try/except ImportError` haette einen falschen Modulpfad verschluckt** — + auf Linux haette der Worker still jeden Rip verweigert. Waechter: + `src/rippy/test_paket.py` (beim Wegnehmen des Moduls rot gesehen). +2. **`gui.py` von CRLF auf LF gekippt** — 1520 Zeilen Diff fuer eine Zeile. + Mein Schreib-Helfer las im Textmodus. Zurueckgedreht. +3. **Ampel-Lauf 170 rot**: Mein Snapshot-Test brauchte eine Datenbank, die + Ampel hat keine. Im Container nachgestellt (Python 3.12, ohne DB): 402 gruen. +4. **`asyncio.get_event_loop()` in einem Worker-Thread** — das ist NICHT die + laufende Schleife, die Coroutine waere nie gelaufen. Schleife wird jetzt im + Startup festgehalten. + +Dazu zwei Formatfehler: `/logs` bildet `ts` -> `timestamp` ab, mein Snapshot +lieferte die rohe DB-Zeile (haette „Invalid Date" gezeigt, NUR im Live-Betrieb); +und ein Docstring versprach eine Ereignis-Reihenfolge, die der Code nicht hielt. + +### WAS ALS NAECHSTES ANSTEHT + +- [ ] **Laufwerk wieder an die VM** (oder klaeren, wo es ist) — ohne das kann + Rippy nicht rippen, und der Windows-Treiber aus V2-4 laesst sich ohne + echtes Laufwerk nicht beweisen, nur behaupten. +- [ ] **V2-4 Windows**: Win32-Treiber, Dienst + Tray, PyInstaller-EXE. + Inno Setup ist auf dem Commander-PC nicht installiert — die EXE kommt + per PyInstaller (womit auch die bestehende RippyWorkerSetup.exe gebaut ist). +- [ ] **V2-5 Docker neu**: ein Image, drei Profile, Host-Mounts statt + Container-Mounts. +- [ ] **V2-7**: neue Funktionen inkl. Schluesselkette in drei Stufen. + +## Letzter Stand davor: v4.0-alpha — Rippy v2 beginnt, Etappe V2-0 steht (28.08.2026) > **Zwei Dinge sind passiert: Das Konzept für Rippy v2 liegt vor und ist vom > Commander entschieden — und die erste Etappe ist gebaut, geprüft und grün.**