Christoph Emsenhuber
c024f85579
- Seeder tp36-cf-estate-seed.py -> tp44-cf-estate-seed.py (+ Referenzen, Docstring) - teilprojekte.md: TP44 Quick-Index + Abschnitt (Anker), Ist-Stand 09-06, TP34/36/37 auf korrigierten Stand (TP37 P3 via TP44 erledigt; P1+2 offen) - Plan-Runbook handoff-20260906-tp37-34-36-plan.md (native Modelle, Compliance-Gegenprobe) - 09-02-Handoff + cf-tunnel-mapping: Referenzen/TODOs nachgezogen - TP23-Quick-Index-Zeile (fremde, korrekte Aenderung) auf User-Okay mit uebernommen Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
128 lines
7.2 KiB
Markdown
128 lines
7.2 KiB
Markdown
# Handoff 2026-09-06 — Plan TP37 (P1+2) → TP34, TP36 parallel
|
||
|
||
> **Sessiontyp:** „erst planen, nichts bauen" (User-Entscheid 2026-09-06). **Kein Nautobot-Write.**
|
||
> Dieses Dokument ist der verzahnte Runbook für die drei nachfolgenden Build-Sessions.
|
||
> Datenmodell-Entscheid: **native Nautobot-Modelle, keine eigene App** (konsistent zu TP44).
|
||
|
||
## 1. Ausgangslage — live gegen die API gelesen (2026-09-06)
|
||
|
||
| | Wert | Bedeutung |
|
||
|---|---|---|
|
||
| Nautobot | `http://10.40.20.30:8080`, v3.1.7 | Apps: **Golden Config 3.0.7 + Nornir** (cloud-Modelle sind Core) |
|
||
| Devices | 9 | 4 aktive MikroTik + decommissioned/Rest — in Build-Schritt 0 verifizieren |
|
||
| **VirtualMachines** | **0** | TP37 P1 offen |
|
||
| **Clusters** | **0** | TP37 P1 offen |
|
||
| **ipam.Service** | **0** | TP37 P2 offen |
|
||
| **CustomFields** | **0** | TP36 offen |
|
||
| Relationships / Tags | 0 / 0 | — |
|
||
| `cloud.*` (Account/ResType/Network/Service) | 1 / 6 / 4 / 14 | ✅ **TP44 Etappe 1** — CF-Estate steht |
|
||
|
||
**Kernbefund:** TP37 **Punkt 3 (CF-Connectoren) ist durch TP44 erledigt** (native cloud-Modelle). Echt
|
||
offen bleibt das **Substrat** (P1) und die **Dienste** (P2) — und genau darauf sitzt TP34.
|
||
|
||
## 2. Entscheidungen (User, 2026-09-06)
|
||
|
||
1. **Erst planen, nichts bauen** — diese Session schreibt nichts nach Nautobot.
|
||
2. **Native Modelle** — `virtualization.Cluster/VirtualMachine` + `ipam.Service`, **keine eigene App**.
|
||
3. **TP44-Doku aufgeräumt** — Quick-Index-Zeile + Abschnitt in `teilprojekte.md`, Seeder
|
||
`nautobot/tp36-…` → `tp44-cf-estate-seed.py` umbenannt.
|
||
|
||
## 3. Reihenfolge / Abhängigkeit (korrigiert)
|
||
|
||
```
|
||
TP37 P3 (CF-Connectoren) ─── ✅ ERLEDIGT via TP44 ───┐
|
||
│ gleiche native-Modell-Linie
|
||
TP37 P1 (Hosts/Container → VirtualMachine) │
|
||
└─► TP37 P2 (Dienste → ipam.Service) ─► TP34 (Caddyfile via GC)
|
||
|
||
TP36 (CustomFields auf den 4 Devices + Datei-Split) ── ∥ unabhängig, jederzeit parallel
|
||
```
|
||
|
||
**Grund für die Unabhängigkeit von TP36:** seine Live-Daten-CustomFields hängen an den **bestehenden
|
||
`dcim.Device`**, nicht an neuen VM/Service-Objekten. TP34 dagegen kann ohne die Backend-`ipam.Service`
|
||
aus P2 nichts rendern → **TP37 vor TP34** bleibt zwingend.
|
||
|
||
---
|
||
|
||
## 4. TP37 Punkt 1 — Substrat: Hosts + Container als VMs
|
||
|
||
**Modell-Mapping (nativ):**
|
||
- `virtualization.ClusterType`: `Proxmox VE`, `Synology Docker`, `Docker Desktop`.
|
||
- `virtualization.Cluster`: `pve`, `nas-bf`, `macmini` (je einer, passender ClusterType).
|
||
*(Die physischen Hosts als eigene `dcim.Device` sind **optional** und kommen frühestens in einer
|
||
Etappe 2 — für den Doku-SSoT reicht der Cluster als Gruppierung. Empfehlung: Etappe 1 ohne Host-Devices.)*
|
||
- `virtualization.VirtualMachine` je Workload, mit `cluster` + `primary_ip4`:
|
||
- **pve:** alle LXCs (u.a. `platform-pg` 105/`.20.20`, Docker-LXC 400/`.20.126`, `mcast-relay` 108,
|
||
influxdb, MariaDB 302/`.20.23`, …).
|
||
- **nas-bf (DS923, Portainer ep14):** Nautobot-Stack-Container, ggf. Caddy/weitere.
|
||
- **macmini (Docker Desktop):** `n8n`/`n8n-redis`/`n8n-mcp`/`gitea-mcp` + terpene-Worker `:8890`.
|
||
|
||
**Build-Schritt 0 (read-only Inventur, BEVOR geseedet wird):** je Host die Workloads mit Name, Rolle,
|
||
primärer IP enumerieren — `pct list` + `pct config <id>` über **pve-mcp**, Portainer-API (ep14) für die
|
||
NAS, `docker ps` auf dem macmini. Ergebnis in eine **Inline-Datenstruktur** (Muster: `tp44-cf-estate-seed.py`)
|
||
→ idempotenter Seeder `nautobot/tp37-substrat-seed.py` (get-or-create, Dry-Run default, `--commit`).
|
||
|
||
## 5. TP37 Punkt 2 — Dienste als `ipam.Service`
|
||
|
||
- Je exponiertem Port ein `ipam.Service`, an die VM (bzw. später das Device) gebunden, das ihn betreibt:
|
||
Caddy `:80/:443`, AdGuard `:53` (bf1/bf2), Nautobot `:8080`, n8n `:5678`, HA `:8123`, Portainer `:9443`,
|
||
`pve-mcp :3000`, gitea, Vaultwarden, …
|
||
- **Quelle ohne Raten:** die Ports stehen in `CLAUDE.md` (Hardware/Tooling) **und** in den
|
||
`extra_config.origin/port`-Feldern der TP44-`CloudService`-Objekte — gegeneinander abgleichen.
|
||
- Idempotenter Seeder `nautobot/tp37-dienste-seed.py`.
|
||
|
||
## 6. 🔴 Auflage: Compliance-Gegenprobe (aus TP37 selbst)
|
||
|
||
Nach P1+2 **muss** `python3 nautobot/gc-transaktion.py status` bzw. `gc-configplan.py --refresh-compliance`
|
||
zeigen, dass die Geräte-Compliance **unverändert 140/140** ist. VMs/Services hinzuzufügen darf die
|
||
Golden-Config-Pipeline der 4 MikroTik **nicht** berühren. P1 und P2 sind je ein **abnehmbarer** Schritt
|
||
mit dieser Gegenprobe danach — nicht als Nebeneffekt von etwas anderem.
|
||
|
||
---
|
||
|
||
## 7. TP34 — Caddyfile via Golden Config (nach P2)
|
||
|
||
- **Vorbedingung:** Backend-Dienste existieren als `ipam.Service` (P2).
|
||
- **Modell (nativ):** Proxy-Route = **Relationship** (oder CustomField) Frontend `caddy`-Service ↔ Backend-
|
||
Service, plus den öffentlichen Hostname am Backend. GC-Job + Jinja rendert den Caddyfile, Diff gegen
|
||
live `caddy-bf1`, neue ComplianceRule `caddyfile`.
|
||
- **Schritt 0 / Quick-Win (sobald gebaut wird):** `terpene.teilzeitladen.xyz → http://10.40.20.167:8890`
|
||
als **manueller** Caddy-Block, damit terpene läuft, bevor die GC-Pipeline steht.
|
||
- ⚠️ **Offener Design-Punkt:** Caddy ist **kein RouterOS-Gerät** — GC an ein Nicht-Netzgerät zu deployen
|
||
(Caddy-Reload) ist neu (die „nicht in TP37"-Grenze). Deploy-Pfad in der TP34-Build-Session entscheiden.
|
||
|
||
## 8. TP36 — Live-Daten-CustomFields + Datei-Split (parallel)
|
||
|
||
- **CustomFields auf `dcim.Device`:** `ros_version`, `compliance_pct`, `dhcp_server_count`, `mgmt_ip`,
|
||
`dns_upstream_mode`. Compliance-Zahl kommt aus **GC selbst**, der Rest aus MikroMCP/REST.
|
||
- **Skript `nautobot/gc-snapshot.py`** (neu — existiert noch nicht): liest live, setzt die CFs, rendert
|
||
`docs/teilprojekte-aktuell.md` als **read-only Snapshot**.
|
||
- **Datei-Split:** `teilprojekte-index.md` (nur aktive TPs, eine Zeile) · `teilprojekte-aktuell.md`
|
||
(Live-Snapshot) · `teilprojekte-archiv.md` (unverändert). `/projektstatus` liest **Index + Archiv**.
|
||
- **Unabhängig von TP37** → kann sofort/parallel starten.
|
||
|
||
---
|
||
|
||
## 9. Empfohlene Reihenfolge der Build-Sessions
|
||
|
||
1. **TP37 P1** (Substrat) — Inventur → Seeder → Compliance-Gegenprobe.
|
||
2. **TP37 P2** (Dienste) — schließt an P1 an, gleiche Gegenprobe.
|
||
3. **TP34** — nach P2 (Quick-Win terpene als Schritt 0).
|
||
4. **TP36** — jederzeit parallel zu 1–3.
|
||
|
||
## 10. Offene Entscheidungen je Build-Session (nicht heute)
|
||
|
||
- **TP34:** Proxy-Route-Modell (Relationship vs. CustomField) + Caddy-Deploy-Pfad (GC an Nicht-Netzgerät).
|
||
- **TP37:** Hosts als eigene `dcim.Device` anlegen oder nur Cluster? (Empfehlung: Etappe 1 nur Cluster.)
|
||
- **TP36:** genaues Feld-Set + wie oft `gc-snapshot.py` läuft (Bot analog golden-config vs. on-demand).
|
||
|
||
## 11. Was diese Session geändert hat (nur Doku)
|
||
|
||
- `nautobot/tp36-cf-estate-seed.py` → **`nautobot/tp44-cf-estate-seed.py`** umbenannt (+ 4 Referenzen,
|
||
+ Docstring-Titel TP36→TP44).
|
||
- `teilprojekte.md`: Quick-Index-Zeile TP44; Ist-Stand-Bullet 2026-09-06; TP34/TP36/TP37-Abschnitte auf
|
||
den korrigierten Stand gezogen; **neuer TP44-Abschnitt** mit Anker.
|
||
- `handoff-20260902-cf-estate-nautobot-ssot.md` + `cf-tunnel-mapping.md`: Dateiname-Referenzen + erledigte
|
||
TODOs nachgezogen.
|
||
- **TP23-Quick-Index-Zeile** (fremde, korrekte Fremd-Änderung ✅→⏳) auf User-Okay mit übernommen.
|