409 lines
35 KiB
Markdown
409 lines
35 KiB
Markdown
# Aufbau Cluster „knaster“ – zusammengeführter Umsetzungsplan
|
||
|
||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||
|
||
**Goal:** Die fünf installierten Proxmox-Knoten werden Schritt für Schritt zum Cluster „knaster“ ausgebaut, auf dem die Architektur aus `docs/PLAN.md` läuft. Grundlage sind die echte Hardware und die Aufgaben aus Planner Epic 7.
|
||
|
||
**Architecture:** Fünf Proxmox-Knoten mit ZFS bilden einen Cluster. Jeder GPU-Knoten bekommt **eine** Ubuntu-VM, an die alle seine Karten durchgereicht werden; darin laufen Docker-Container pro Rolle. Die Infrastruktur (Router, Postgres, Monitoring) läuft als LXC mit Docker und HA. Die beiden RTX-4000-Ada-Rechner bleiben Windows-Arbeitsplätze und stellen ihre Leistung über die vorhandene Worker-Registry v2 bereit. Starke Modelle laufen ausschließlich über den LiteLLM mit PSE auf appsrv08.
|
||
|
||
**Tech Stack:** Proxmox VE 9.2 (Debian 13, ZFS), Ubuntu 24.04 in den GPU-VMs, NVIDIA R580 (Maxwell/Pascal), llama.cpp, whisper.cpp, Docker Compose, OpenTofu (`bpg/proxmox`), Ansible, Prometheus/Alertmanager/Grafana, Proxmox Backup Server, n8n (n8n.mindboost.app), LiteLLM (appsrv08), Python-Paket `knaster`.
|
||
|
||
**Spec/Quellen (bei der Umsetzung mitlesen):**
|
||
- `docs/PLAN.md`, `docs/adr/0001`–`0006`, `docs/IMPLEMENTATION.md`, `docs/BETRIEB.md` (dieses Repo)
|
||
- Planner „Epic 7 — CCO KI-Agent Infrastruktur“ (Plan `NLQ0gHCZkUmdMv3ko__DmZgAHU_S`, Bucket `IeG9IcsEG0-_ZEW5unBaiZgAEtoE`)
|
||
- `C:\Users\r.rapp\it\proxmox\STAND-2026-10-08.md` und `healthcheck-2026-10-08.txt` (Ist-Stand der Knoten)
|
||
- Repo `mygodel/nex`: `docs/plans/2026-10-07-nex-stt-gpu.md` (Whisper im Haus), `docs/plans/2026-09-29-nex-worker-registry-v2.md` (Ada-Worker)
|
||
|
||
Dieser Plan **löst** die Abläufe in `docs/PLAN.md` §8 („Roadmap“) und `docs/IMPLEMENTATION.md` („Gemeinsames Deployment“) **ab**. Deren Phasen sind unten zugeordnet.
|
||
|
||
---
|
||
|
||
## Ausgangslage (Stand 12.10.2026)
|
||
|
||
| Knoten | IP | Hardware | Platten | GPUs | Besonderheit |
|
||
|---|---|---|---|---|---|
|
||
| pve44 | 192.168.100.210 | ThinkStation P310, i7-6700, 32 GB | 2× 256 GB (sdb: altes Windows, NTFS) | M4000 + P2000 | – |
|
||
| pve46 | 192.168.100.209 | ThinkStation P310, i7-6700, 32 GB | 1× 256 GB | M4000 + P2000 | bootet Legacy statt UEFI |
|
||
| pve48 | 192.168.100.212 | **unbekannt** | unbekannt | unbekannt | kein SSH (Passwort aus `.env` falsch) |
|
||
| pve52 | 192.168.100.207 | ThinkStation P320, i7-7700, 32 GB | 2× 256 GB (sdb: altes Windows, **BitLocker „GODEL55“**) | M4000 (P2000 nicht erkannt) | – |
|
||
| pve61 | 192.168.100.214 | Surface Book, i5-8350U, 8 GB | 1× 256 GB NVMe | Intel UHD 620 | LAN nur über USB-NIC im Lenovo-Dock, 2 Akkus |
|
||
|
||
Alle Knoten: PVE 9.2.2, Kernel 7.0.2, **ext4 + LVM-thin auf einer SSD (kein ZFS)**, 1 GbE, kein Cluster. VT-x und VT-d sind aktiv. IOMMU ist geprüft: Jede Karte liegt mit ihrer Audio-Funktion in einer eigenen Gruppe (M4000 in Gruppe 1, P2000 in Gruppe 8), Passthrough ist also möglich.
|
||
|
||
Außerhalb des Clusters:
|
||
- **GODE-PC-05/06:** laut Nutzer zwei Geräte mit vermutlich je einer RTX 4000 Ada (20 GB). Das Repo-Inventar nahm zwei Karten in einem Gerät an, deshalb wird das in Task 0.1 geprüft. Windows, tagsüber Arbeitsplätze, laufen heute schon als LLM-Worker (`LocalLLMWorker.ps1`).
|
||
- **appsrv08 (.29):** GRP produktiv, NEX und LiteLLM mit PSE-Filter.
|
||
- **n8n:** n8n.mindboost.app.
|
||
- **Gitea:** gitea.mindboost.team.
|
||
|
||
---
|
||
|
||
## Global Constraints
|
||
|
||
- **Starke Modelle (tier0, OpenRouter) nur über den LiteLLM mit PSE auf appsrv08.** Kein zweiter Gateway-Weg nach außen, sonst wird die Pseudonymisierung umgangen (Epic 7 „LiteLLM Swarm: PSE-Fix“).
|
||
- **Netz:** flach `192.168.100.0/24`, Gateway `.1`, DNS `.120`. Feste IP-Literale, kein DNS-Name in Konfigurationen, vorerst kein VLAN.
|
||
- **Container zuerst:** Dienste laufen als Docker-Container, in LXC oder in einer VM. Eine VM gibt es nur dort, wo sie ein Treiberproblem löst (GPU-VM pro Knoten, D2) oder ein Produkt sie verlangt.
|
||
- **Dry-Run:** Alle knaster-Aktionen gegen Infrastruktur starten mit `KNASTER_DRY_RUN=true` und werden erst nach einer Woche Beobachtung einzeln freigeschaltet.
|
||
- **STT:** `whisper-server` auf Port 8178, nur von `192.168.100.29` erreichbar. `stt.openai.base_url` nur als IP-Literal (nex-STT-Plan, Annahmen).
|
||
- **Ada-Rechner:** Windows bleibt, Mitarbeitende haben tagsüber Vorrang, kein Proxmox darauf.
|
||
- **Datacenter-weite Einstellungen** (Benutzer, 2FA, Firewall, Benachrichtigungen, Pools, Metriken) erst, wenn alle Knoten im Cluster sind.
|
||
- **Alte Windows-SSDs** (pve44 sdb, pve52 sdb) nur nach ausdrücklicher Freigabe löschen (D1).
|
||
- **Geheimnisse** nie ins Repo. Zugangsdaten liegen in `C:\Users\r.rapp\it\proxmox\.env`, der Schlüssel unter `…\proxmox\keys\`.
|
||
- **Planner-Webhook `tdo-codex-update`:** pro Aufruf nur **eine** Aktualisierung, vorhandene Titel nie umbenennen (Abgleich läuft über den Titel, Schwelle 0.8).
|
||
|
||
## Review Focus
|
||
|
||
1. **Eine Neuinstallation löscht die Einrichtung vom 08.10.** Betroffen sind Schlüssel, Paketquellen, Dock-Bindung und SSH-Hostschlüssel. Erwartung: Das Bootstrap-Skript stellt alles wieder her, und `ssh -o BatchMode=yes pveXX hostname` klappt danach ohne Nachfrage (Task 1.1, Test im Skript).
|
||
2. **Der Cluster-Beitritt ersetzt `authorized_keys`.** Erwartung: Nach jedem `pvecm add` funktioniert der Laptop-Zugang auf allen Knoten weiter (Task 2.1, Prüfschritt).
|
||
3. **Die USB-NIC von pve61 verschwindet nach einem Stromausfall oder einem Umstecken des Docks.** Erwartung: `vmbr0` hängt danach wieder an der Karte, ohne Eingriff (Task 1.3, Test: Dock aus- und einstecken).
|
||
4. **Ein Ada-Worker ist tagsüber belegt oder aus.** Erwartung: tier1-Anfragen landen ohne Fehler bei tier0 über PSE (Task 6.4, Unit-Test im Router).
|
||
5. **Die Rolle `pve-host` sperrt NVIDIA und setzt VFIO.** Erwartung: Das passiert nur auf GPU-Knoten. pve61 behält seine iGPU für den Kiosk (Task 3.1, Ansible-Gruppen, Prüfung `lspci -k`).
|
||
|
||
---
|
||
|
||
## Entscheidungen (vor der jeweiligen Phase bestätigen)
|
||
|
||
| # | Frage | Empfehlung | Begründung | Alternative |
|
||
|---|---|---|---|---|
|
||
| **D1** | Speicher | **B – keine Neuinstallation:** Die System-SSD bleibt, wie sie ist. Die zweite SSD wird remote per SSH zum ZFS-Pool `tank` (pve44, pve52, ggf. pve48). pve46 und pve61 bleiben ohne ZFS. | Kein Einsatz vor Ort, und es bleibt mehr Platz (256 GB System plus 256 GB `tank` statt 256 GB gespiegelt). Das entspricht dem ursprünglichen ADR-0002 („SSD 1 System, SSD 2+ `tank`“). Replikation und HA für den Infra-LXC laufen zwischen pve44 und pve52. Fällt eine System-SSD aus, wird dieser Knoten neu installiert; die Gäste sind repliziert. | **A – Neuinstallation mit ZFS** (vor Ort, USB-Stick, Monitor, Tastatur): RAID1 auf Knoten mit zwei SSDs, `local-zfs` überall, Systemplatte gespiegelt, pve46 auf UEFI. Lässt sich später je Knoten nachholen. |
|
||
| **D2** | GPU als VM oder LXC | **Pro GPU-Knoten eine Ubuntu-24.04-VM mit allen Karten des Knotens**, darin Docker Compose pro Rolle. | Der Host-Kernel (7.0) bleibt ohne NVIDIA, Proxmox-Updates gefährden den Treiber nicht. R580 kommt als Ubuntu-Paket und ist per Snapshot rückrollbar. IOMMU-Gruppen sind geprüft. Eine VM pro Knoten statt pro Rolle (ADR-0001) spart RAM. Das Argument „gemischte Generationen“ aus ADR-0001 gilt im Cluster nicht mehr, alle Karten sind Maxwell/Pascal. Kosten: 2–5 % CPU, fest reservierter VM-RAM (12–16 GB von 32 GB). | LXC mit Host-Treiber: braucht R580 auf Kernel 7.0 oder einen festgehaltenen älteren Kernel. |
|
||
| **D3** | Ada-Rechner | **Windows bleibt.** `LocalLLMWorker.ps1` mit llama-server (CUDA) meldet sich über die Worker-Registry v2. Die knaster-Slots `tier1-general`/`tier1-flex` lösen auf einen Worker auf, der online ist, sonst tier0. | Die Registry v2 ist fast fertig (44 von 55 Schritten). Mitarbeitende werden nicht gestört. vLLM läuft unter Windows nicht nativ, Multi-LoRA, QLoRA und Qwen3-TTS kommen deshalb erst mit einer späteren WSL2-Entscheidung (Phase 9). | Dual-Boot mit Proxmox: scheidet aus, die Rechner werden tagsüber genutzt. |
|
||
| **D4** | LiteLLM | **Kein eigener LiteLLM im knaster-Infra.** Der Router nutzt den LiteLLM auf appsrv08 (mit PSE), die lokalen Slots werden dort als Modelle eingetragen. | Es läuft bereits ein dritter LiteLLM; noch einer würde PSE für tier0 umgehen. Ein Modellwechsel bleibt eine Datenänderung. | Eigener LiteLLM nur für lokale Slots, ohne OpenRouter-Zugang. |
|
||
| **D5** | IP-Plan | **Knoten behalten .207–.214.** Gäste bekommen einen festen Block außerhalb des DHCP-Bereichs. Vorschlag `.220–.239`, wird in Task 0.3 gegen den DHCP-Bereich geprüft. | Die STT-Konfiguration braucht IP-Literale. Die alten GODEL-DNS-Einträge zeigen, dass die Knoten-IPs aus DHCP stammen, deshalb Reservierungen anlegen. | VLAN `svc` (PLAN §1.4) später, wenn der Switch das zulässt. |
|
||
|
||
## RAM-Budget je Knoten
|
||
|
||
Bei einem Knoten mit 32 GB sind 6 GB fest belegt: 2 GB für den Host und 4 GB ZFS-ARC. Eine GPU-VM reserviert ihre 12 GB vollständig, Passthrough erlaubt kein Ballooning. Damit bleiben auf einem GPU-Knoten **14 GB** für Container und als Reserve für den Failover.
|
||
|
||
| Gast | RAM | pve48 ohne GPU (Task 0.1) | pve48 mit GPU |
|
||
|---|---|---|---|
|
||
| `gpu-pve44`, `gpu-pve46`, `gpu-pve52` (ggf. `gpu-pve48`) | je 12 GB, fest | auf dem eigenen Knoten | auf dem eigenen Knoten |
|
||
| `infra` (LXC) | 8 GB | pve48, Replikation nach pve44 (nur wenn pve48 eine zweite SSD für `tank` hat, sonst wie rechts) | pve44, Replikation nach pve52 |
|
||
| `ops` (LXC) | 1 GB | pve48 | pve46 |
|
||
| `pbs` (VM) | 4 GB | pve48 | pve52 |
|
||
| `grp-test` (LXC) | 4 GB | pve48 | pve46 |
|
||
| pve61 | 8 GB gesamt | keine Gäste, nur Kiosk | keine Gäste, nur Kiosk |
|
||
|
||
Regeln:
|
||
- Die Summe der Gäste je Knoten bleibt bei höchstens 26 GB (32 − 6).
|
||
- Das Replikationsziel von `infra` hat immer mindestens 8 GB frei, sonst scheitert der HA-Neustart still.
|
||
- Prüfung nach jedem neuen Gast: `pvesh get /nodes/<knoten>/status --output-format json | jq .memory`.
|
||
|
||
---
|
||
|
||
## Phase 0 – Bestandsaufnahme und Repo an die Wirklichkeit anpassen
|
||
|
||
Ersetzt PLAN §8 „0 Fundament“ (Teil Inventar) und IMPLEMENTATION „Gemeinsames Deployment“ Schritt 1.
|
||
|
||
### Task 0.1: Zugang zu pve48 und Inventar aller Knoten
|
||
|
||
**Wo:** Teil a vor Ort an der Konsole von pve48, Teil b remote · **Planner:** „Proxmox: pve48 root-Passwort klären und SSH-Schlüssel nachtragen“
|
||
|
||
- [ ] **a (vor Ort):** An pve48 als root anmelden, gegebenenfalls `passwd`, neuen Wert in `.env` (`PVE48_PASS`) eintragen.
|
||
- [ ] **b:** Schlüssel verteilen (Verfahren vom 08.10., `push_keys.py`) und Paketquellen umstellen.
|
||
Prüfung: `ssh -o BatchMode=yes pve48 hostname` → `pve48`.
|
||
- [ ] **c:** Gesundheitscheck auf pve48 ausführen und `healthcheck-2026-10-08.txt` ergänzen. Notieren: CPU, RAM, Platten, GPUs, IOMMU-Gruppen.
|
||
- [ ] **d (vor Ort, falls nötig):** pve52 – steckt neben der M4000 eine P2000? Falls ja: Sitz und Steckplatz prüfen, bis `lspci | grep -c NVIDIA` zwei VGA-Geräte zeigt. Verbleib von Godel45 klären (im STT-Plan aufgeführt).
|
||
- [ ] **e:** Ada-Rechner GODE-PC-05/06: Karte und VRAM je Gerät mit `nvidia-smi -L` erfassen, an der Konsole oder über die Worker-Registry. Erwartet wird je Gerät eine Zeile `RTX 4000 Ada Generation`.
|
||
|
||
### Task 0.2: DHCP-Bereich und IP-Plan (D5)
|
||
|
||
**Wo:** remote (DHCP-Server, vermutlich DC `.120` oder UniFi) · **Planner:** „PVE-Config: Netzwerk prüfen – Bridge, VLAN-Fähigkeit und NIC-Kompatibilität“
|
||
|
||
- [ ] DHCP-Bereich auslesen. Für .207, .209, .210, .212 und .214 Reservierungen auf die MACs der Knoten anlegen (MACs stehen im Healthcheck). Ebenso eine Reservierung für den Admin-Laptop (heute .151 per WLAN). Die Firewall in 4.4 lässt nur diese Adresse zu, ein Lease-Wechsel würde sonst aussperren.
|
||
- [ ] Gäste-Block festlegen (Vorschlag `.220–.239`) und als Ausschluss im DHCP eintragen.
|
||
Prüfung: `ping` auf jede Adresse des Blocks → keine Antwort. DHCP-Ausschluss sichtbar.
|
||
|
||
### Task 0.3: Entscheidungen D1–D5 bestätigen
|
||
|
||
**Wo:** Gespräch mit dem Nutzer
|
||
|
||
- [ ] D1: Ausdrückliche Freigabe zum Löschen von pve44 sdb (NTFS) und pve52 sdb (BitLocker „GODEL55“). Vorher klären, ob Daten oder Recovery-Key gebraucht werden.
|
||
- [ ] D2–D5 bestätigen. Ergebnis als Abschnitt „Entscheidungen 2026-10“ in `docs/PLAN.md` §9 eintragen.
|
||
|
||
### Task 0.4: Site-Dateien, Ansible-Inventar und ADRs an die echte Hardware anpassen
|
||
|
||
**Wo:** remote, Repo · **Files:**
|
||
- Modify: `sites/knaster/inventory.yaml`, `sites/knaster/proxmox.yaml`, `sites/knaster/registry.yaml`, `platform/proxmox/ansible/inventory.yml`, `docs/PLAN.md` §1.3, §1.4 und §9
|
||
- Modify: `docs/adr/0001-gpu-vms-infra-lxc.md` (eine VM pro Knoten), `docs/adr/0002-storage-zfs-kein-ceph.md` (D1), `docs/adr/0006-legacy-gpus-llamacpp-tts-auf-ada.md` (Ada unter Windows, D3)
|
||
- Test: `core/tests/test_inventory_validate.py`
|
||
|
||
**Interfaces:**
|
||
- Produces: Proxmox-Knoten `pve44`, `pve46`, `pve48`, `pve52`, `pve61`, dazu die Inventar-Knoten `gode-pc-05` und `gode-pc-06` (Ada, ohne Proxmox, nur im Inventar). PCI-Mappings `gpu-m4000-pve44`, `gpu-p2000-pve44`, `gpu-m4000-pve46`, `gpu-p2000-pve46`, `gpu-m4000-pve52` (plus pve48 nach Task 0.1). GPU-VMs `gpu-pve44` (vmid 244), `gpu-pve46` (246), `gpu-pve52` (252). Infra-LXC `infra` (vmid 101). Ansible-Gruppen `pve_all`, `pve_gpu_hosts`, `pve_kiosk`.
|
||
|
||
- [ ] **Step 1: Failing test.** In `test_inventory_validate.py` den Test `test_site_knaster_matches_real_nodes` anlegen:
|
||
- Die Inventar-Knoten sind genau `{pve44, pve46, pve48, pve52, pve61, gode-pc-05, gode-pc-06}`.
|
||
- `proxmox.yaml` enthält keine IP aus `10.20.0.0/24`.
|
||
- Jedes `pci_mappings[*].node` und jedes `vms[*].node` liegt in `{pve44, pve46, pve48, pve52}`.
|
||
- [ ] **Step 2:** `make test` → FAIL (alte Annahmen `pve-ada`, `pve1`–`pve4`).
|
||
- [ ] **Step 3:** Site-Dateien umschreiben. Werte für IDs und Pfade aus `lspci -nn` und dem Healthcheck: M4000 `10de:13f1` auf `0000:01:00`, P2000 `10de:1c30` auf `0000:02:00`. Gateway `192.168.100.1`, DNS `192.168.100.120`, keine `vlan_svc`, Gast-IPs aus D5. Die M4000 bleiben `disabled: true` bis zum Benchmark-Tag (Task 3.3). Die Ada-Slots (`tier1-general`, `tier1-flex`, `tts-de-hq`) behalten vorerst ihre Engine. In `registry.yaml` entfallen bei ihnen nur `pve_node` und `vmid`. Die Umstellung auf die Worker-Registry folgt in Task 6.4.
|
||
- [ ] **Step 4:** `make test && make validate` → PASS. `knaster placement plan --inventory sites/knaster/inventory.yaml` liefert eine Zuordnung ohne Fehler.
|
||
- [ ] **Step 5:** Commit `sites: Inventar und Zielbild an echte Knoten (pve44–pve61) angepasst; ADR-0001/0002/0006 ergänzt`.
|
||
|
||
---
|
||
|
||
## Phase 1 – Knoten-Grundlage (vor dem Cluster)
|
||
|
||
### Task 1.1: Bootstrap-Skript für einen frischen Knoten
|
||
|
||
**Wo:** remote · **Planner:** „PVE-Config: Erst-Update aller Knoten (apt full-upgrade)“ · **Files:** Create `platform/proxmox/scripts/bootstrap-node.sh`, Create `platform/proxmox/scripts/README.md`
|
||
|
||
**Interfaces:**
|
||
- Produces: `bootstrap-node.sh <knoten>`, idempotent. Ausgabe endet mit `BOOTSTRAP OK <hostname>` oder Exit ≠ 0.
|
||
|
||
- [ ] **Step 1:** Das Skript (läuft auf dem Laptop, Git-Bash) erledigt Folgendes:
|
||
- alten Hostschlüssel mit `ssh-keygen -R <ip>` entfernen
|
||
- Schlüssel per Passwort aus `.env` eintragen, mit dem SSH_ASKPASS-Verfahren vom 08.10. (nur anhängen, `grep -qxF`)
|
||
- Enterprise-Quellen auf `Enabled: no` setzen, `proxmox.sources` mit `pve-no-subscription` anlegen, vorher sichern
|
||
- `apt-get update && apt-get -y full-upgrade`
|
||
- Pakete `ethtool lm-sensors` installieren
|
||
- Prüfen: `timedatectl show -p NTPSynchronized` = `yes`
|
||
- [ ] **Step 2:** Zweiter Lauf gegen denselben Knoten → keine Änderung, wieder `BOOTSTRAP OK`.
|
||
- [ ] **Step 3:** Commit.
|
||
|
||
### Task 1.2: Speicher (D1)
|
||
|
||
**Planner:** „Proxmox: Speicher aller Knoten richtig konfigurieren“ (enthält die frühere Aufgabe zur RAM-Planung)
|
||
|
||
**Variante B (Empfehlung) – remote, ohne Neuinstallation**
|
||
|
||
- [ ] Freigabe aus Task 0.3 liegt vor. Dann auf pve44 und pve52 (ggf. pve48): Partitionen von `sdb` mit `wipefs -a /dev/disk/by-id/<ssd2>` entfernen, danach `zpool create -o ashift=12 -O compression=lz4 -O atime=off tank /dev/disk/by-id/<ssd2>` und `pvesm add zfspool tank --pool tank --content images,rootdir --nodes pve44,pve52`.
|
||
Das Löschen ist nicht umkehrbar. Vorher `lsblk -o NAME,SIZE,FSTYPE,LABEL /dev/sdb` prüfen: Es muss die freigegebene Windows-Platte sein, nie `sda`.
|
||
- [ ] ZFS-ARC auf 4 GiB begrenzen (`/etc/modprobe.d/zfs.conf`, `update-initramfs -u`, wirksam beim nächsten Neustart).
|
||
Prüfung: `zpool status tank` → `ONLINE`. `pvesm status` → `tank active` auf beiden Knoten.
|
||
|
||
**Variante A – Neuinstallation mit ZFS**
|
||
|
||
**Wo:** **vor Ort**, USB-Stick mit PVE 9.2 (ISO und Prüfsumme in `C:\Users\r.rapp\it\proxmox`)
|
||
|
||
Reihenfolge: **pve46** (eine Platte, Legacy → UEFI), dann pve44, pve52, pve48 und zuletzt **pve61 mit angestecktem Dock** (der USB-C-Adapter ist zurückgegeben).
|
||
|
||
- [ ] Pro Knoten: BIOS auf UEFI, Secure Boot aus. Installer: gleicher Hostname und gleiche IP wie bisher, `ZFS (RAID1)` bzw. `ZFS (RAID0)` bei einer Platte, `ashift=12`, `compress=on`.
|
||
- [ ] **Prüfpunkt iGPU (GPU-Knoten):** Im BIOS die Onboard-Grafik als primäre Anzeige einstellen und den Monitor ans Mainboard anschließen.
|
||
Prüfung: Die Proxmox-Konsole erscheint am Mainboard-Anschluss.
|
||
Rückfall, falls das BIOS die iGPU bei eingesteckter Karte abschaltet: die P2000 in Steckplatz 1 und die M4000 in Steckplatz 2 tauschen. Die Boot-Grafik ist dann die P2000; für sie gilt beim Passthrough in Task 3.2 `x-vga`/ROM-Prüfung.
|
||
- [ ] Neues root-Passwort trägt der Nutzer **vor** dem nächsten Schritt in `.env` ein (`PVExx_PASS`), sonst scheitert das Bootstrap-Skript.
|
||
- [ ] Danach `bootstrap-node.sh <knoten>` → `BOOTSTRAP OK`.
|
||
- [ ] ZFS-ARC begrenzen: `zfs_arc_max` = 4 GiB auf 32-GB-Knoten, 1 GiB auf pve61 (`/etc/modprobe.d/zfs.conf`, `update-initramfs -u`).
|
||
Prüfung: `zpool status` → `ONLINE`. `pvesm status` → `local-zfs active`. `cat /sys/module/zfs/parameters/zfs_arc_max` → `4294967296` bzw. `1073741824`.
|
||
|
||
### Task 1.3: pve61 – Netzwerk am Dock robust machen, Akku schonen
|
||
|
||
**Wo:** remote, Akku-Einstellung vor Ort · **Planner:** Teil von „Proxmox: pve61 (Surface) zeigt das Grafana-Dashboard als Kiosk“
|
||
|
||
- [ ] NIC des Docks per systemd-`.link` auf den Namen `nic0` festlegen, Zuordnung über die MAC `3c:e1:a1:c0:83:9d`. `bridge-ports nic0` in `/etc/network/interfaces`. Nach dem Ausstecken hängt ein `udev`-Hook `ifup`/`ifreload` die Karte wieder an `vmbr0`.
|
||
- [ ] **Test (vor Ort):** Dock 10 s ausstecken und wieder einstecken → nach höchstens 30 s `ping 192.168.100.214` vom Laptop ok.
|
||
- [ ] Surface-UEFI „Battery Limit“ einschalten (Lauter-Taste + Einschalten).
|
||
Prüfung: `grep . /sys/class/power_supply/BAT*/capacity` pendelt bei etwa 50 %.
|
||
|
||
---
|
||
|
||
## Phase 2 – Cluster
|
||
|
||
Ersetzt GPU-Knoten 3 (Teil Cluster). Mit 5 Stimmen ist **kein QDevice** nötig.
|
||
|
||
### Task 2.1: Cluster „knaster“ bilden
|
||
|
||
**Wo:** remote · **Planner:** „GPU-Knoten 3: Cluster mit QDevice (Container auf appsrv08), NVIDIA-Treiber, GPU-Container“ (Teil Cluster)
|
||
|
||
- [ ] Auf pve44: `pvecm create knaster --link0 192.168.100.210`.
|
||
- [ ] Nacheinander auf pve46, pve48, pve52 und pve61: `pvecm add 192.168.100.210 --link0 <eigene IP>`. Nach **jedem** Beitritt den Laptop-Schlüssel in `/etc/pve/priv/authorized_keys` prüfen und gegebenenfalls einmal ergänzen.
|
||
Prüfung: `pvecm status` → `Quorate: Yes`, `Total votes: 5`. `for n in pve44 pve46 pve48 pve52 pve61; do ssh -o BatchMode=yes $n hostname; done` → fünf Namen.
|
||
- [ ] Datacenter-Optionen: Migrationsnetz `192.168.100.0/24`, Typ `secure`.
|
||
|
||
### Task 2.2: HA-Regeln und Replikation
|
||
|
||
**Wo:** remote
|
||
|
||
- [ ] Node-Affinity-Regeln: Infra-Dienste nur auf pve44, pve48, pve52. **pve61** bekommt keine HA-Gäste, GPU-VMs bleiben an ihrem Knoten.
|
||
- [ ] Replikationspartner festlegen: Infra-LXC von seinem Knoten auf einen zweiten, `*/15`.
|
||
Prüfung: `ha-manager rules config` bzw. `ha-manager groupconfig` zeigt die Regeln.
|
||
|
||
---
|
||
|
||
## Phase 3 – GPU-Grundlage und Benchmark-Tag
|
||
|
||
### Task 3.1: Steuerrechner „ops“ und Host-Rolle nur für GPU-Knoten
|
||
|
||
**Wo:** remote · **Files:** Modify `platform/proxmox/ansible/inventory.yml`, `platform/proxmox/ansible/playbooks/site.yml`, Create `platform/proxmox/README.md` (Abschnitt ops-LXC)
|
||
|
||
- [ ] LXC `ops` (Debian 13, vmid 100, auf pve44, IP aus D5) mit `ansible-core`, `opentofu`, `git` und dem Repo-Clone. Ansible läuft nicht auf dem Windows-Laptop.
|
||
- [ ] `site.yml`: `pve-host` nur für `pve_gpu_hosts` (pve44, pve46, pve52, ggf. pve48). pve61 steht in `pve_kiosk` ohne VFIO und Blacklist.
|
||
- [ ] Rolle `pve-host` ergänzen: `/etc/modprobe.d/vfio.conf` mit `options vfio-pci ids=<liste>` und `softdep nvidia pre: vfio-pci`. Die Liste enthält die Grafik- **und** die Audio-Funktionen der Karten. Die IDs aus `lspci -nn -s 01:00` und `lspci -nn -s 02:00` auf dem Knoten lesen, nicht aus dem Gedächtnis eintragen; bekannt sind bisher nur die VGA-IDs `10de:13f1` und `10de:1c30`.
|
||
- [ ] `ansible-playbook playbooks/site.yml --limit pve_gpu_hosts --check`, danach der echte Lauf. Knoten **einzeln** neu starten.
|
||
Prüfung: `lspci -nnk -s 01:00` und `lspci -nnk -s 02:00` auf jedem GPU-Knoten → bei allen Funktionen `Kernel driver in use: vfio-pci`. Auf pve61: `lspci -k -s 00:02.0` → `i915`.
|
||
|
||
### Task 3.2: Resource Mappings, Template und GPU-VMs
|
||
|
||
**Wo:** remote (ops-LXC) · **Planner:** „GPU-Knoten 3 …“ (Teil NVIDIA, GPU-Container)
|
||
|
||
- [ ] PCI-Resource-Mappings aus `sites/knaster/proxmox.yaml` anlegen (Namen aus Task 0.4).
|
||
- [ ] Ubuntu-24.04-Cloud-Template vmid 9000 auf jedem GPU-Knoten.
|
||
- [ ] `tofu plan` und dann `tofu apply` für `gpu-pve44`, `gpu-pve46` und `gpu-pve52`: alle Karten des Knotens, 12 GB RAM, 4 Kerne, Systemplatte 40 GB und Modellplatte 60 GB auf `local-zfs`, IPs aus D5.
|
||
- [ ] `ansible-playbook … --limit gpu_vms` (Rollen `docker-host` und `gpu-node`, `driver_generation: legacy` = R580).
|
||
Prüfung in jeder VM: `nvidia-smi -L` → beide Karten. `docker run --rm --gpus all nvidia/cuda:12.6.3-base-ubuntu24.04 nvidia-smi` → beide Karten.
|
||
|
||
### Task 3.3: Benchmark-Tag (fasst drei Pläne zusammen)
|
||
|
||
**Wo:** remote, **Strommessung vor Ort** (Messgerät an der Steckdose) · **Planner:** „GPU-Knoten 4: Geschwindigkeitstests (Gate) auf M4000 und P2000“ · ersetzt außerdem den „Benchmark-Tag“ aus IMPLEMENTATION und den Gate-Task 1 des nex-STT-Plans
|
||
|
||
- [ ] `llama-bench` je Kartentyp: Embedding-Modell, 3–4B Q4 (verifier/signature), 7B Q4. Tokens/s und VRAM messen.
|
||
- [ ] whisper.cpp `large-v3-turbo`, Sprache `de`: Sekunden je 10 s Diktat auf M4000 und P2000. Klärt, ob CC 5.2 überhaupt rechnet. Zusätzlich die Dialekt-Testsätze.
|
||
- [ ] `knaster bench tts` (Piper, CPU).
|
||
- [ ] Strom je Knoten: Leerlauf und Volllast beider Karten (400-W-Netzteil, erwartet etwa 300 W).
|
||
- [ ] Ergebnis eintragen in `catalog/models.yaml` und `sites/knaster/registry.yaml`, in ADR-0006 „M4000 wieder aufnehmen ja/nein“ und in die STT-Entscheidung D131/D133 (nex). Commit.
|
||
Prüfung: `make validate` → PASS, Placement ordnet jede aktive Rolle einer gemessenen Karte zu.
|
||
|
||
---
|
||
|
||
## Phase 4 – Cluster-Grundkonfiguration (erst wenn alle Knoten drin sind)
|
||
|
||
**Wo:** remote. Jede Aufgabe hier entspricht einer Planner-Aufgabe.
|
||
|
||
- [ ] **4.1 Benutzer und Token** („PVE-Config: Persönlicher Admin-Benutzer, Rollen und API-Token anlegen“): Admin-Benutzer und Gruppe, root@pam nur als Notfallzugang. Token `monitoring@pve!prom` (PVEAuditor), `healer@pve!knaster` (nur `VM.PowerMgmt` auf GPU-VMs, PLAN §3), `tofu@pve!ops`.
|
||
- [ ] **4.2 2FA** („PVE-Config: Zwei-Faktor-Authentifizierung für Admin-Konten aktivieren“): TOTP für root@pam und Admin. Recovery-Keys offline ablegen.
|
||
- [ ] **4.3 Benachrichtigungen** („PVE-Config: Benachrichtigungen (Notification Center) einrichten“): SMTP-Ziel Büro-Postfach, Matcher für Backup, Fencing und Updates. Testnachricht kommt an.
|
||
- [ ] **4.4 Firewall** („PVE-Config: Firewall auf Datacenter- und Knotenebene einrichten“): IP-Set `admin` (Laptop) und `appsrv08` (.29). Zuerst Allow-Regeln für 8006, 22 und ICMP, **dann** aktivieren. Konsole als Rückfall bereithalten. Prüfung: Weboberfläche vom Laptop ok, von einem anderen Rechner gesperrt.
|
||
- [ ] **4.5 Ordnung** („PVE-Config: Ressourcenpools und Tags festlegen“, „PVE-Config: Standard für neue LXC-Container festlegen“): Pools `infra`, `gpu`, `test`. Tags `gpu`, `infra`, `test`. LXC-Standard: unprivilegiert, Debian-13-Vorlage, Nesting nur für Docker.
|
||
- [ ] **4.6 Zertifikat** („PVE-Config: Web-GUI-Zertifikat festlegen (niedrige Priorität)“): `/etc/pve/pve-root-ca.pem` auf dem Laptop als vertrauenswürdig importieren.
|
||
- [ ] **4.7 Update-Routine** („PVE-Config: Update- und Neustart-Routine festlegen (rollierend, Knoten für Knoten)“): Ablauf in `docs/BETRIEB.md` eintragen (Wartungsmodus, ein Knoten nach dem anderen, GPU-VMs vorher sauber stoppen).
|
||
|
||
---
|
||
|
||
## Phase 5 – Backup und Monitoring
|
||
|
||
### Task 5.1: Proxmox Backup Server
|
||
|
||
**Wo:** remote, Speicherort vor Ort · **Planner:** „Proxmox: Backup-System überlegen“ (beantwortet PLAN §9, offener Punkt 6)
|
||
|
||
- [ ] Ziel-Speicher entscheiden. Empfehlung: externer Datenträger oder NAS, **nicht** die Toshiba-Platte „BACKUP“ des Nutzers. PBS als VM `pbs` (vmid 110), Datastore auf dem Ziel.
|
||
- [ ] Jobs: nächtlich Infra-LXC, ops-LXC und GPU-VMs (ohne Modellplatte), Aufbewahrung 7 Tage, 4 Wochen und 6 Monate. Dazu ein wöchentlicher Verify-Job.
|
||
- [ ] **Restore-Test:** Infra-LXC als Kopie zurückspielen.
|
||
Prüfung: Die Kopie startet, `docker ps` zeigt die Dienste.
|
||
|
||
### Task 5.2: Infra-LXC mit Monitoring (ein Stack)
|
||
|
||
**Wo:** remote · **Planner:** „Proxmox: Grafana-Dashboard für den Cluster“, „PVE-Config: Verfügbarkeits-Monitoring und Log-Kontrolle ergänzen“ · **Files:** Modify `deploy/compose/infra/docker-compose.yml`, `deploy/prometheus/prometheus.yml`
|
||
|
||
- [ ] `deploy/compose/infra` ohne den Dienst `litellm` (D4). Router zeigt auf `http://192.168.100.29:<LiteLLM-Port>`. Image-Tags pinnen (offener Punkt aus IMPLEMENTATION).
|
||
- [ ] LXC `infra` (vmid 101, Nesting, 4 Kerne, 8 GB, Knoten laut RAM-Budget) mit HA und Replikation (Task 2.2). Compose mit `KNASTER_DRY_RUN=true`.
|
||
- [ ] Prometheus-Ziele: `pve-exporter` (Token aus 4.1), `node-exporter` und `nvidia_gpu_exporter` in den GPU-VMs, Router.
|
||
- [ ] Grafana: Dashboards für Proxmox, Knoten, GPU (Community-JSON) und knaster. Konto `kiosk` mit Rolle Viewer.
|
||
- [ ] Alertmanager an den Router (Healer, Dry-Run) und an n8n `knaster-notify`. Der Workflow wird inaktiv importiert, dann aktiviert.
|
||
Prüfung: Grafana zeigt alle 5 Knoten und alle GPUs. Ein Test-Alert (`amtool alert add test`) erscheint im Kanal.
|
||
|
||
### Task 5.3: Kiosk auf pve61
|
||
|
||
**Wo:** remote, Abnahme vor Ort · **Planner:** „Proxmox: pve61 (Surface) zeigt das Grafana-Dashboard als Kiosk“
|
||
|
||
- [ ] Empfehlung: minimaler Kiosk **direkt auf dem Host** (`cage` + `chromium` als eigener Benutzer, systemd-Dienst, Bildschirmschoner aus). Das ist eine bewusste kleine Ausnahme von „Container zuerst“, weil ein Kiosk Bildschirm und Eingabe des Geräts braucht.
|
||
- [ ] URL: Grafana-Playlist im Kiosk-Modus mit Konto `kiosk`.
|
||
Prüfung: Nach einem Neustart von pve61 zeigt der Bildschirm ohne Eingriff das Dashboard.
|
||
|
||
---
|
||
|
||
## Phase 6 – Data Plane
|
||
|
||
Ersetzt PLAN §8 „1 Data Plane“.
|
||
|
||
- [ ] **6.1 GPU-Rollen:** `deploy/compose/gpu-llamacpp` in den GPU-VMs nach der Zuordnung aus Task 3.3, also Embedding und Rerank redundant auf zwei Knoten, Chat für verifier und signature. Prüfung: Canary-Checks grün (`knaster` Canary-Prober).
|
||
- [ ] **6.2 STT** (nex-STT-Plan Tasks 2–4): `whisper-server` als zusätzlicher Dienst in der GPU-VM des in Task 3.3 gewählten Knotens. Neuer Slot `stt-de` im Katalog. Port 8178 nur von `192.168.100.29` (Firewall der VM bzw. des Gasts). Prüfung: Von appsrv08 liefert `curl -F file=@probe.wav http://<IP>:8178/v1/audio/transcriptions` deutschen Text, von einem anderen Rechner wird der Zugriff abgelehnt.
|
||
- [ ] **6.3 Lokale Slots in LiteLLM (D4):** `embed-default`, `rerank-default`, `verifier-small` und `signature-extractor` als Modelle im LiteLLM auf appsrv08 eintragen (IP-Literale). Prüfung: `curl http://192.168.100.29:<port>/v1/models` listet die Slots, ein Aufruf je Slot antwortet.
|
||
- [ ] **6.4 Ada-Worker (D3)** · **Planner:** „LLM-Worker: direkte Inferenz-Schnittstelle für LiteLLM (zusätzlich zum Job-Poll), Tunnel, Registry, Fallback-Kette“
|
||
- Offene Schritte der Worker-Registry v2 im Repo `mygodel/nex` abschließen.
|
||
- Gefilterte Ports auf GODE-PC-05/06 freigeben (nex-STT-Plan, Anhang A).
|
||
- Im knaster-Router `engine: worker-registry` umsetzen: `GET /webhook/llm-worker-list` lesen und einen Worker wählen, der online ist; sonst Eskalation auf tier0.
|
||
- Tests in `core/tests/test_router.py`:
|
||
- `test_worker_registry_slot_uses_online_worker`
|
||
- `test_worker_registry_slot_falls_back_to_tier0_when_list_empty`
|
||
- `test_worker_registry_slot_falls_back_when_list_unreachable`
|
||
- Prüfung: `make test` PASS. Live tagsüber geht eine tier1-Anfrage an tier0, nachts an GODE-PC-05.
|
||
|
||
---
|
||
|
||
## Phase 7 – Kernpfad
|
||
|
||
Ersetzt PLAN §8 „2 Kernpfad“.
|
||
|
||
- [ ] n8n-Workflows `knaster-request`, `knaster-jobs` und `knaster-service-routine` inaktiv importieren und Credentials setzen (`n8n/README.md`).
|
||
- [ ] Ende-zu-Ende: Eine Anfrage läuft über Router, Verifier und Eskalation über den PSE-LiteLLM. Die Dry-Run-Woche beginnt.
|
||
- [ ] Nex-STT-Plan Tasks 5–8: Hermes-Overlay `stt.openai.base_url` mit IP-Literal, Rückfall auf CPU, Abnahme.
|
||
- [ ] Offen und hier zu entscheiden: Langfuse (PLAN §2.4) steht nicht im Infra-Compose.
|
||
|
||
## Phase 8 – GRP als Testdienst
|
||
|
||
**Planner:** „Proxmox: GRP als Testservice in einen LXC-Container umziehen“ · **Voraussetzung:** PBS (Task 5.1)
|
||
|
||
- [ ] LXC `grp-test` (Pool `test`, Docker) mit einer Kopie der GRP-Daten von appsrv08. Die Produktion bleibt unangetastet. Feste IP aus D5, Zugriff nur intern.
|
||
Prüfung: Die Testinstanz läuft, das Backup des Containers ist im PBS sichtbar.
|
||
|
||
## Phase 9 – knaster-Ausbau (eigene Pläne folgen)
|
||
|
||
Die Software-Phasen aus PLAN §8 bleiben inhaltlich gültig und bekommen jeweils einen eigenen Plan:
|
||
- „3 Skills“: Hermes als Skill-Autor
|
||
- „4 Robustheit“: Healer live, Aktionen einzeln freischalten
|
||
- „5 Lifecycle“: QLoRA-Training. Voraussetzung ist die Entscheidung über WSL2 bzw. vLLM auf den Ada-Rechnern nachts (D3, Folgeentscheidung).
|
||
- „6 Portabilität“
|
||
|
||
Am Ende von Phase 9 wird das Betriebshandbuch abgeschlossen („PVE-Config: Betriebshandbuch und Testvorgehen anlegen“). Das geschieht als Erweiterung von `docs/BETRIEB.md`, nicht als neues Dokument.
|
||
|
||
---
|
||
|
||
## Parallelspur NEX (ohne Cluster-Bezug, nach Dringlichkeit)
|
||
|
||
| # | Planner-Aufgabe | Warum jetzt |
|
||
|---|---|---|
|
||
| P1 | LiteLLM Swarm: PSE-Fix ausrollen (Klartext-Abfluss) | Datenschutz-Leck auf dem Swarm (D4 nutzt den schon reparierten LiteLLM auf appsrv08) |
|
||
| P2 | NEX: Startpasswort astreit ändern | Passwort lag lesbar in S:\IT\Nex |
|
||
| P3 | NEX aufräumen: Testinstanz, Schlüsseldateien | `ca.key` liegt ungeschützt |
|
||
| P4 | NEX: Gitea/Portainer-Schritte für Port je Agent und Registry (Teil 1 der Checkliste) | blockiert nex-admin |
|
||
| P5 | nex-admin 1: eigene Tokens anlegen und Stack nex deployen → nex-admin 2 → nex-admin 3 → nex-admin 4 | in dieser Reihenfolge |
|
||
| P6 | NEX - Admin Mail in n8n anlegen und Wächter-Mail testen | nach nex-admin 1 |
|
||
| P7 | Arbeitsplatz-Setup-Skript am eigenen PC testen | unabhängig |
|
||
| P8 | NEX Websuche: eigenes SearXNG im Stack nex | unabhängig |
|
||
|
||
---
|
||
|
||
## Zuordnung Epic 7 → Plan (Duplikate zusammengeführt)
|
||
|
||
| Planner-Aufgabe (exakter Titel) | Im Plan | Planner-Aktion nach Freigabe |
|
||
|---|---|---|
|
||
| Proxmox: pve48 root-Passwort klären und SSH-Schlüssel nachtragen | Task 0.1 | bleibt |
|
||
| PVE-Config: Netzwerk prüfen – Bridge, VLAN-Fähigkeit und NIC-Kompatibilität | Task 0.2 (D5), VLAN später | bleibt, Beschreibung ergänzen |
|
||
| Proxmox: Konfiguration aller Knoten durcharbeiten | aufgeteilt auf 0.1, 1.1–1.3 | schließen mit Verweis auf diesen Plan |
|
||
| PVE-Config: Erst-Update aller Knoten (apt full-upgrade) | Task 1.1 | bleibt |
|
||
| Proxmox: Speicher aller Knoten richtig konfigurieren | D1, Task 1.2 | bleibt |
|
||
| PVE-Config: RAM-Planung je Knoten (Host-Reserve, ZFS-ARC, KSM, Swap) | Task 1.2 (ARC), Task 3.2 (VM-RAM) | **zusammengeführt** in „Speicher …“, schließen |
|
||
| GPU-Knoten 3: Cluster mit QDevice (Container auf appsrv08), NVIDIA-Treiber, GPU-Container | Tasks 2.1, 2.2, 3.1, 3.2 | bleibt (Titel unverändert), Beschreibung: kein QDevice, GPU als VM |
|
||
| GPU-Knoten 4: Geschwindigkeitstests (Gate) auf M4000 und P2000 | Task 3.3 (mit knaster-Benchmark-Tag und STT-Gate) | bleibt, Beschreibung ergänzen |
|
||
| PVE-Config: Persönlicher Admin-Benutzer, Rollen und API-Token anlegen | 4.1 | bleibt |
|
||
| PVE-Config: Zwei-Faktor-Authentifizierung für Admin-Konten aktivieren | 4.2 | bleibt |
|
||
| PVE-Config: Benachrichtigungen (Notification Center) einrichten | 4.3 | bleibt |
|
||
| PVE-Config: Firewall auf Datacenter- und Knotenebene einrichten | 4.4 | bleibt |
|
||
| PVE-Config: Ressourcenpools und Tags festlegen | 4.5 | bleibt |
|
||
| PVE-Config: Standard für neue LXC-Container festlegen | 4.5 | **zusammengeführt** in „Ressourcenpools …“, schließen |
|
||
| PVE-Config: Web-GUI-Zertifikat festlegen (niedrige Priorität) | 4.6 | bleibt |
|
||
| PVE-Config: Update- und Neustart-Routine festlegen (rollierend, Knoten für Knoten) | 4.7 | bleibt |
|
||
| Proxmox: Backup-System überlegen | Task 5.1 | bleibt |
|
||
| Proxmox: Grafana-Dashboard für den Cluster | Task 5.2 (knaster-Stack statt InfluxDB) | bleibt, Beschreibung ändern |
|
||
| PVE-Config: Verfügbarkeits-Monitoring und Log-Kontrolle ergänzen | Task 5.2 (Alertmanager, Healer) | **zusammengeführt** in „Grafana-Dashboard …“, schließen |
|
||
| Proxmox: pve61 (Surface) zeigt das Grafana-Dashboard als Kiosk | Tasks 1.3, 5.3 | bleibt |
|
||
| LLM-Worker: direkte Inferenz-Schnittstelle für LiteLLM (zusätzlich zum Job-Poll), Tunnel, Registry, Fallback-Kette | Task 6.4 | bleibt, Beschreibung: Registry v2 + knaster-Brücke |
|
||
| Proxmox: GRP als Testservice in einen LXC-Container umziehen | Phase 8 | bleibt |
|
||
| PVE-Config: Betriebshandbuch und Testvorgehen anlegen | Phase 9 (`docs/BETRIEB.md`) | bleibt |
|
||
| P1–P8 (NEX-Aufgaben) | Parallelspur | bleiben |
|
||
|
||
**Neu angelegt** (nur Schritte ohne bestehende Aufgabe, keine Duplikate):
|
||
- „knaster: Entscheidungen D1–D5 bestätigen“ (0.3)
|
||
- „knaster: Site-Dateien und ADRs an echte Hardware anpassen“ (0.4)
|
||
- „knaster: GPU-Dienste (llama.cpp) in den GPU-VMs“ (6.1)
|
||
- „knaster: STT-Dienst whisper-server im Haus“ (6.2)
|
||
- „knaster: lokale Slots im LiteLLM auf appsrv08“ (6.3)
|
||
- „knaster: Kernpfad Ende-zu-Ende im Dry-Run“ (Phase 7)
|
||
|
||
Cluster und GPU-VMs laufen über „GPU-Knoten 3“, der Infra-LXC über „Proxmox: Grafana-Dashboard für den Cluster“.
|
||
|
||
**Zuordnung der knaster-Roadmap (PLAN §8):** 0 Fundament → Phasen 0–5 · 1 Data Plane → Phase 6 · 2 Kernpfad → Phase 7 · 3–6 → Phase 9.
|
||
|
||
**Zuordnung nex-STT-Plan:** Task 0 erledigt · Task 1 → 3.3 · Tasks 2–4 → 6.2 · Tasks 5–8 → Phase 7.
|