Configuration Management
Change management
Linking config changes to support tickets, reusing maintenance windows for scheduled pushes, the state of approval-before-apply, and the real who/what/when audit trail.
Config change → ticket linkage
Real, additive, built this pass (sql/167_config_change_ticket_linkage.sql). configs (005) and bulk_push_batches (147) had no way to record which support ticket, if any, a change was made in response to -- verified directly before writing anything, no such column existed anywhere. An optional ticket_id, nullable, referencing the real tickets table (045), now exists on every config-producing write path:
- Rollback -- the "Ticket (optional)" picker on the confirm-rollback row, Config diff and rollback.
- Golden-config template apply -- the "Ticket (optional)" picker next to the apply-to-node picker, on this Configuration Management overview page's own Golden config templates panel.
- Bulk / canary push -- the "Ticket (optional)" picker on the create-batch form, Bulk and fleet operations. Recorded once per batch and copied onto every device's own new config row.
Optional everywhere it was added -- most config writes (routine operator work, automated rollout stages) genuinely have no ticket behind them, and forcing one would fabricate a linkage that isn't real for the common case.
Loading…