Christoph Emsenhuber
dc639b0a55
Der Port trug keines der sieben VLANs, deshalb war ap1 nach dem Umpatchen tot. Sieben set-Zeilen ueber gc-manual-plan.py, und der erste Deploy zeigte gleich zwei bekannte Fallen von ihrer praktischen Seite: Der Plan meldete Failed, und der Teilzustand war real -- sechs VLANs hatten ether3 bekommen, VLAN 40 nicht. Der Grund ist sauber: ether3 war dort UNTAGGED-Mitglied, und ein Port kann in derselben VLAN nicht zugleich tagged und untagged sein. Nachtrag deployt (untagged=ether2,ether4,ether5), diesmal mit --assert, und der hat den Effekt am Geraet nachgewiesen statt dem Job zu glauben. Ergebnis: ap1 antwortet in 447 us und traegt wieder 12 Clients (ap2: 16). Die Aenderung bleibt bewusst UNCOMMITTED: sie steht am Geraet, nicht in der SoT, und die Compliance meldet den Drift auf bridge-vlan. Genau so soll es sein, solange offen ist, ob ap1 am Sideboard bleibt. Faellt die Entscheidung, wird entweder das Template nachgezogen (commit) oder aus dem Snapshot zurueckgebaut. Ein Bugfix im neuen Werkzeug faellt dabei gleich mit an: der Feature-Name steht bei depth=1 nicht ausgeschrieben in rule.feature, dort kommt nur eine URL. Verwendbar ist rule.display. Ohne das meldete status JEDEN Drift als "ausserhalb des Scopes" -- also ausgerechnet die Zuordnung falsch, fuer die es gebaut wurde. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Transaktionen — Teständerungen mit Ablaufdatum
Hier liegen die Akten offener und geschlossener Config-Transaktionen. Werkzeug:
nautobot/gc-transaktion.py.
Wozu
Eine Änderung, die am Gerät 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".
Eine Transaktion macht die Absicht sichtbar, ohne die Governance aufzuweichen: der Change geht
weiterhin ausschließlich über Golden Config (gc-manual-plan.py), und die Compliance meldet den
Drift weiterhin. Neu ist nur, dass status ihn zuordnen kann.
| SQL | hier |
|---|---|
BEGIN |
Snapshot des Scope-Abschnitts + Akte mit Gerät, Scope, Grund und Ablaufdatum |
| uncommitted | Change ist am Gerät wirksam und im Testumfeld sichtbar, aber nicht in der SoT |
COMMIT |
Template/Config-Context nachziehen → Compliance grün → Akte schließen |
ROLLBACK |
Rückbau-Vorschlag aus dem Snapshot, prüfen, deployen, Akte schließen |
Drei Regeln, die das Werkzeug erzwingt
--expiresist Pflicht. Eine offene Transaktion ohne Frist ist undokumentierter Drift mit besserem Gewissen.statusmarkiert überfällige Akten.- Der Scope ist eine ComplianceRule, kein Freibrief. Driftet etwas außerhalb des Scopes, meldet
statusdas ausdrücklich als nicht abgedeckt. - Eine offene Transaktion je Gerät — sonst ist beim Rollback nicht mehr entscheidbar, wohin zurück.
Zwei bewusste Grenzen
- Der Rollback pusht nicht selbst. Er schreibt einen Vorschlag aus dem Snapshot;
add-Zeilen aus einem/exportlegen neu an, statt zu ändern, und brauchen meist einset [find …]. Ein Rückbau, den niemand gelesen hat, ist genau die Sorte Automatik, die hier schon zweimal teuer war. - Der Snapshot enthält nur den Scope-Abschnitt. Ein voller
/exportenthält Firewall, Adressen, Benutzerliste und Skriptquellen — nichts davon wird für den Rückbau gebraucht, und diese Akten liegen im Git. Für den Ernstfall gibt es das binäre/system backupauf dem Gerät (--device-backup).
Dateien je Transaktion
| Datei | Inhalt |
|---|---|
<change-id>.json |
die Akte: Gerät, Scope, Grund, Fristen, Status |
<change-id>.snapshot.rsc |
der Scope-Abschnitt vor der Änderung |
<change-id>.commands.rsc |
was deployt wurde |
<change-id>.rollback.rsc |
erst nach rollback — der Vorschlag zum Prüfen |