bf-infra/docs/handoff-20260902-cf-estate-nautobot-ssot.md

Handoff 2026-09-02 — CF-Estate als SSoT in Nautobot (TP44, Etappe 1)

Scope: die Cloudflare-Infrastruktur (Tunnel + App-Ebene) als strukturierte, abfragbare SSoT in Nautobot abbilden. Etappe 1 = manuelle Erstbefüllung über die nativen nautobot.cloud-Modelle. Ausgelöst aus der DB-Pfad-Session (siehe cf-tunnel-mapping.md §17).

Entscheidung (User, 2026-09-02)

• SSoT-Modus: Etappen — manuell jetzt, Sync später. cf-tunnel-mapping.md wird zum Snapshot/Zeiger.
• Scope Etappe 1: volle CF-Estate (Tunnel + WARP-Connector + VPC-Service + Hyperdrive + Workers + alle Access-Apps).
• Grundsatz: Nautobot kann CF nicht steuern → „SSoT" = Dokumentations-SSoT. CF bleibt operativer Master.

Warum ein eigenes TP (TP44), nicht TP36

TP36 ist in teilprojekte.md eng auf teilprojekte.md-Live-Daten + Datei-Aufteilung geschnitten. Dieselbe Idee (Nautobot als Doku-SSoT), aber andere Dimension → TP44 (nächste freie Nummer nach TP43). Quick-Index-Zeile + TP-Abschnitt in teilprojekte.md sind noch offen (die Datei trug bei dieser Session fremde, ungestagte Änderungen — bewusst nicht mit angefasst, um den Commit sauber zu halten).

Modell (Nautobot 3.1.7, App nautobot.cloud)

Manufacturer "Cloudflare"
  └─ CloudAccount "Cloudflare" (account_number = 393c051f3accf51881d6c98fc5b66c36)
       ├─ CloudResourceType ×6
       │    cloudflared Tunnel · WARP Connector        → cloud.cloudnetwork
       │    VPC Service · Hyperdrive · Worker · Access Application → cloud.cloudservice
       ├─ CloudNetwork ×4   bf-public · fm.emsenhuber.net · terpene-db · bf-core-mesh
       └─ CloudService ×14  VPC terpene-db · Hyperdrive terpene(ro)+terpene-rw ·
                            Worker terpene+blaueblueten-n8n · 9× Access-App

• IDs/Ports/Hostnames/Origins liegen je Objekt in extra_config (JSON).
• Service↔Tunnel-Verknüpfung über das Through-Modell cloud-service-network-assignments (3 Rows): terpene-db↔terpene-db, *.emsenhuber.net↔bf-public, hass, vw, gitea↔bf-public.
• Prefix-Routen (10.40.0.0/16 bf-core-mesh, 10.101.0.0/24 fm) sind nicht als cloud-network-prefix-assignments gesetzt, weil die Prefixe nicht in IPAM existieren → in extra_config.route belassen (best-effort im Seeder, greift automatisch, sobald die Prefixe in IPAM sind).

Werkzeug

nautobot/tp44-cf-estate-seed.py — idempotenter Seeder (get-or-create), Datenstand als Inline-Struktur. Token aus docs/nas-vlan20/stacks/210-nautobot.yml (gitignored). Aufruf: Dry-Run default, --commit schreibt. Re-Run = 26/26 „existiert". (Datei am 2026-09-06 von tp36-… auf tp44-cf-estate-seed.py umbenannt — Präfix jetzt korrekt.)

Gotchas (für Etappe 2 / Folgesessions)

• 🔴 CloudService.cloud_networks ist im Serializer read_only und bleibt bei GET leer — die Verknüpfung wird ausschließlich über cloud-service-network-assignments geschrieben UND gelesen. Nicht am leeren Convenience-Feld verzweifeln; die Through-Rows sind die Wahrheit.
• VPC-Service-API liegt unter connectivity/directory/services (Update = PUT, voller Body), nicht /vpc/.
• Der Repo-CF_API_TOKEN darf cfd_tunnel, aber nicht Workers-VPC (connectivity/directory) — dort über den cloudflare-MCP-Credential gehen.

Offen (Etappe 2, eigene Session)

1. CF-API→Nautobot-Sync (Python/n8n): Inline-Daten im Seeder durch Live-Pull ersetzen, periodisch (analog golden-config-bot). Dann ist Nautobot driftfrei.
2. ✅ TP44 in teilprojekte.md eingetragen (Quick-Index + Abschnitt + Ist-Stand) — 2026-09-06.
3. IPAM-Prefixe 10.40.0.0/16 + 10.101.0.0/24 anlegen → dann greifen die Prefix-Assignments automatisch.
4. ✅ Seeder-Datei nach tp44-cf-estate-seed.py umbenannt — 2026-09-06.

Verifikation (2026-09-02)

Counts: CloudAccount 1 · ResourceType 6 · CloudNetwork 4 · CloudService 14 · Service-Network-Assignments 3. Idempotenz-Gegenprobe grün.