19. Operations

The network operator’s home: device inventory, drift, and the change-proposal queue, all driven by your source of truth.

At a glance

If you operate a network, Operations is your home page. It pulls device inventory, drift detection, the change-proposal queue, and bulk inventory upload into one surface — everything driven by your source of truth (the concept is Chapter 14).

Top-level layout

Tabs across the top, left to right:

• Overview — vocabulary refresher + the three KPIs (devices, in-sync, open drift) + jump-offs to the other tabs.
• Devices — the inventory page.
• Drift — the live-drift list.
• Proposals — every change proposal, kinds of all sorts.
• Bulk import — upload YAML or Excel to seed your inventory.
• Routine runs — history of reconciler and other agent runs.

We’ll cover each.

Devices tab

The Devices tab is your device inventory. Each row is one device (router, switch, firewall, load balancer, etc.) being watched by the SoT reconciler.

Columns:

• Hostname
• Vendor / Model
• Site
• Role (e.g., edge router, leaf switch)
• In sync? — green ✓ if the last reconciler run found no drift; amber if there’s open drift; gray if not yet reconciled.
• Last seen — when the reconciler last successfully reached the device.
• ⋯ — actions.

Filter bar at the top: site, vendor, role, in-sync status, search by hostname.

Click any row to drill into the device detail page:

• Identity — all the fields from Nautobot plus device-side info (uptime, software version, serial number).
• Live config — the current running config, syntax highlighted. “Diff against SoT” shows the drift if any.
• History — past drifts and their resolutions; past config changes pushed through Daalu.
• Run diagnostics — buttons for the kinds of read-only ops the device supports (show version, show neighbors, etc.).
• Reconcile now — trigger an immediate reconciler run for this device.

Drift tab

A filtered view of the Devices tab showing only currently- drifted devices. Each row also shows:

• A diff summary (“ACL acl-10 has 3 lines added, 1 removed”).
• The age of the drift (when it was first detected).
• The proposed action (“Apply Nautobot config to device” or “Update Nautobot to match device” — chosen by the reconciler based on heuristics).
• Direct Open proposal link.

This is the page a NetOps team’s daily standup tends to start on.

Proposals tab

The full queue of change proposals. Operations → Proposals shows every kind:

• kind=drift — auto-detected drift remediation.
• kind=ai-suggested — generated by the Assistant.
• kind=manual — opened by a human directly.
• kind=workflow — opened by a workflow you authored.

Columns:

• Title — short description.
• Kind — see above.
• Target — which device / cluster / resource.
• Status — proposed, approved, applied, denied, error.
• Author — user, Assistant, reconciler, or workflow.
• Created.
• Action buttons — approve / deny inline if you’re eligible.

Click any row for the detail page:

• Summary — human-readable description of what will happen.
• Diff — the structured change. For device configs, a side- by-side syntax-highlighted diff.
• Plan — the literal sequence of tool calls that will run if approved.
• Approvals — who can approve, who has approved.
• Comments — threaded discussion (each comment is also a notification to subscribed users).
• Audit log — every transition with timestamp and actor.

How a drift proposal flows

End-to-end, here’s the lifecycle:

1. Reconciler runs at 09:00. It reads device config from edge-router-3, reads the Nautobot intended config, sees acl-10 has been edited on the device but not in Nautobot.
2. Reconciler writes a proposal: title “Drift on edge-router-3 (ACL acl-10)”, kind=drift, target=device-id, plan=“apply intended config to device.”
3. Proposal appears on the Drift and Proposals tabs.
4. Operator opens it, reads the diff. Decides: “Actually the device-side change was intentional; we just forgot to commit. Update Nautobot to match.”
5. Operator clicks “Update Nautobot instead” on the proposal. The plan rewrites: “update Nautobot’s intended config for device-id to match live.”
6. A second operator (the four-eyes rule prevents the first from approving) reviews and approves.
7. Executor runs the plan: calls Nautobot’s API to update the intended config. Records audit-log row.
8. Proposal status → applied. Reconciler’s next run sees “no drift” and records the device as in-sync.

The whole loop is auditable. The post-mortem question “why does this device have this config?” is always answerable from the proposals history.

Bulk import tab

If you’re onboarding a brand-new tenant, manually adding 200 devices through Add device is not going to be your friend. The Bulk import tab lets you upload your whole inventory in one shot.

Accepted formats:

• YAML — a top-level devices: list (or a bare top-level list) of records.
• Excel (.xlsx) — first sheet, first row = headers (case-insensitive). Empty rows are skipped.

Required columns: name, primary_ip, transport, site, device_type, role. The platform column is optional.

Names in the catalog fields (site, device_type, role, platform) resolve case-insensitively against your Nautobot — you don’t have to look up UUIDs.

The flow is always two-phase:

1. Upload. Daalu parses + validates against your catalog and shows a row-by-row preview. Valid rows are green; rows with errors are red, with the reason next to them. Nothing has been written to Nautobot at this point.
2. Apply. When you’re happy, click Apply N devices. Daalu creates each valid row sequentially, skipping the bad ones. The preview table updates in place to show which rows were created and any per-row errors that surfaced during the actual Nautobot calls.

Tip: re-uploading the same file is harmless if you only fixed the rows that errored — Nautobot will 4xx on duplicate names, which surfaces as a per-row error rather than blowing away your batch. Edit the file to only include the rows you want to retry, or rename the duplicates.

Routine runs tab

A history view of all automated runs that touched Operations:

• Reconciler runs (every device, every cycle).
• Assistant-initiated tool calls.
• Workflow executions.

Each row shows: actor, timestamp, target, success/failure, and a link to the structured artifact (proposal, diff, response).

Useful when you’re debugging “why didn’t the reconciler catch X?” or “did the workflow run at 02:00 like it was supposed to?”

On-demand reconciliation

Two ways to force a reconciler run:

• Per device. From a device’s detail page, click Reconcile now. The reconciler queues it ahead of the scheduled run.
• Tenant-wide. From Settings → Reconciliation, click Force full reconcile. All devices at once.

Both record in the Routine runs tab.

Per-device reconcile-interval tuning

Some devices are stable and don’t need frequent checks; others are hot. Per-device intervals are configured in Settings → Reconciliation → Per-device overrides (admin-only):

• Default: 5 minutes.
• Allowed range: 30 seconds to 24 hours.
• The reconciler honors the override on the next cycle.

A short interval costs CPU on Daalu’s side and a small load on the device. Don’t drop to 30 seconds across the entire fleet unless you have a reason.

Next: Chapter 20 — Agents