Files
bf-infra/nautobot
Christoph Emsenhuber 3f938e8389 Config-Transaktionen: begin/commit/rollback fuer Testaenderungen
Eine Aenderung, die am Geraet steht, aber nicht in der SoT, ist Drift -- und Drift
sieht bisher immer gleich aus, egal ob er ein Versehen ist oder ein laufender
Versuch. Wer testen wollte, hatte die Wahl zwischen "Compliance kaputt" und "gar
nicht testen".

gc-transaktion.py macht die Absicht sichtbar, ohne die Governance aufzuweichen:
der Change geht weiterhin ausschliesslich ueber Golden Config, die Compliance
meldet den Drift weiterhin -- neu ist, dass `status` ihn zuordnen kann,
"erwartet (offene Transaktion)" statt "unerklaert". Und dass er ein Ablaufdatum
hat.

Drei Regeln erzwingt das Werkzeug: --expires ist Pflicht (eine unbefristete
Ausnahme ist undokumentierter Drift mit besserem Gewissen), der Scope ist eine
ComplianceRule und kein Freibrief (Drift ausserhalb wird ausdruecklich als nicht
abgedeckt gemeldet), und es gibt genau eine offene Transaktion je Geraet -- sonst
ist beim Rollback nicht mehr entscheidbar, wohin zurueck. Der Commit wird
verweigert, solange der Scope noch driftet: dann waere die SoT gar nicht
nachgezogen worden.

Zwei bewusste Grenzen: der Rollback pusht nicht selbst, sondern schreibt einen
Vorschlag zum Pruefen (add-Zeilen aus einem /export legen neu an, statt zu
aendern), und der Snapshot enthaelt nur den Scope-Abschnitt. Der Vollexport
enthielt Firewall, Adressen, Benutzerliste und Skriptquellen -- nichts davon
braucht der Rueckbau, und die Akten liegen im Git.

Erste Akte ist der ether3-Trunk: ap1 haengt testweise am Sideboard auf core
ether3, und dieser Port traegt bisher keines der sieben VLANs. Deploy steht noch
aus -- er wurde in dieser Session vom Berechtigungs-Klassifikator blockiert.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 20:15:05 +02:00
..

Nautobot-Tooling

ingest-baseline.py

Idempotenter Basisdaten-Ingest (Locations, Rollen, Device-Types, Devices, VLANs/Prefixes, ap1-Interfaces + IPs, WLAN-Modelle). Bildet den Ist-Zustand ab, nicht den Zielzustand.

export NAUTOBOT_TOKEN=...          # aus docs/nas-vlan20/stacks/210-nautobot.yml (gitignored)
python3 nautobot/ingest-baseline.py          # Dry-Run
python3 nautobot/ingest-baseline.py --apply  # schreiben

API-Fallen (teuer gelernt)

  • tagged_vlans liest sich per REST als null, obwohl korrekt gespeichert. Verifikation nur über GraphQL: POST /api/graphql/ mit {interfaces(device:"ap1"){name mode untagged_vlan{vid} tagged_vlans{vid}}}.
  • Relationen kommen ohne ?depth=1 ohne display → ein voll gepflegtes Device sieht leer aus.
  • LocationType.content_types muss ipam.vlangroup/ipam.vlan/ipam.prefix/dcim.controller enthalten, sonst 400 beim Anlegen.
  • parent_interface nur für virtuelle Interfaces — WLAN-VAPs können ihren Master nicht als Parent tragen.
  • WirelessNetwork hat kein VLAN-Feld; die VLAN-Bindung hängt an wireless/controller-managed-device-group-wireless-network-assignments und braucht zwingend einen Controller (bei uns logisch, controller_device leer — kein CAPsMAN).
  • RadioProfile.channel_width will Integer ([20,40,80]), nicht "20mhz".
  • IP↔Interface läuft über /ipam/ip-address-to-interface/.