Devices, Inventory & Source of Truth

A list of devices isn't inventory

Picture a text file with three lines in it:

sw-edge-01
sw-edge-02
sw-core-01

That's a list of devices. It's also almost useless to an automation script on its own. Which of these is a switch you can push a config change to, and which is a router you should only ever read from? What platform is each one running — does show run even work the same way on all three? Which credentials should connect to them? Which site are they in, in case something needs a site-specific NTP server?

A hostname alone answers none of that. Structured inventory does — it's the same list, but with the information attached that automation actually needs to act on each device correctly, not just identify it.

What structured inventory actually looks like

Each entry on the right answers the questions a script needs answered before it connects to anything:

• Hostname — a name a human recognizes, used for logging and reporting ("SW-14 is out of sync" means something; "10.10.2.14" doesn't, at a glance).
• Management IP — the actual address the script connects to. Hostnames don't always resolve reliably in every environment; automation typically connects on the IP.
• Platform — what kind of device this is (Cisco IOS, IOS-XE, NX-OS, a different vendor entirely). Commands and config syntax aren't identical across platforms, so a script needs to know this before it decides what to send.
• Groups / roles — what kind of device this is functionally: access switch, core switch, edge router. A task like "push this VLAN to every access switch" needs role information to know which devices qualify — without it, you're back to maintaining a separate list by hand for every task.
• Site — where the device physically or logically sits. Plenty of checks and changes are site-specific — a regional NTP server, a site-specific VLAN range — and "which site" has to come from somewhere.

Credentials: part of the picture, handled differently

Every device in inventory needs credentials to connect — but credentials don't belong sitting in the same plain list as hostnames and IPs, for a reason that should be obvious: that list gets read by scripts, checked into places, and looked at by more than one person. Storing a password in plain text next to a hostname is a real, common way credentials leak.

Conceptually, the right shape is: inventory says which device and what kind of device it is; a separate, protected mechanism (a credential store, environment variables, a secrets vault) supplies how to log in. The script combines the two at connection time. This module isn't the place to implement that — it's just important to understand credentials as a distinct concern from the rest of inventory, not an extra column to add to the same file.

Source of truth: where "correct" actually lives

Once inventory has real structure, it becomes something more specific: a source of truth — the one place automation (and the people running it) trust to say what's actually on the network. If the source of truth says sw-edge-01 is an access switch at site HQ-Fl2, every script that asks "give me all access switches at HQ-Fl2" depends on that being accurate.

This is worth taking seriously, because it cuts both ways. Good inventory makes automation reliable — a script can trust what it's told about a device. Stale or wrong inventory makes automation confidently wrong: a script won't second-guess "role: access" if that's what the source of truth says, even if that switch was actually re-provisioned as something else six months ago and nobody updated the record.

Recognizing inventory that's too thin

Not every list needs every field from day one — a two-switch lab doesn't need a "site" column. But as a rough gut-check, inventory is too thin to automate against reliably once you find yourself needing to ask a person "wait, which of these is the Cisco one?" or "is SW-09 still in production?" before a script can safely run. If a question like that has to be answered by asking around instead of reading the inventory, that's a sign the structure hasn't caught up to what automation actually needs.