Inventory¶
The DRP inventory system collects structured hardware and OS metadata from machines during the discovery
and provisioning pipeline. Inventory data is stored as machine parameters and is used to drive workflow
decisions, hardware classification, compliance checking, and cost tracking. The inventory system is
implemented by the inventory and inventory-minimal stages in the task-library content pack.
What Inventory Tracks¶
The inventory system uses drpcli gohai to collect low-level hardware information from the machine
while it is running in Sledgehammer (or another managed environment). The collected data is processed
through JQ filters defined in the inventory/collect parameter and stored as flat key-value pairs in
inventory/data. Default collected fields include:
- Memory — Total RAM (MB), number of populated DIMM slots, DIMM sizes
- Processors — CPU count, type, speed, and core count
- Networking — NIC count, NIC info (vendor, model, bus address), NIC speed, MAC addresses
- Storage — Disk names, disk IDs, disk paths; RAID controller count and disk inventory
- Display — GPU/display controller count, product, vendor, version
- System identity — Manufacturer, serial number, product name, family, hypervisor presence
- TPM — TPM version and public key (when TPM tooling is available)
Additional inventory sources (RAID controllers, IPMI, HPE iLO) are contributed by their respective content pack stages (raid-inventory, ipmi-inventory, hpe-ilorest-inventory).
How Machines Get Added to Inventory¶
Inventory collection occurs as part of the discovery or provisioning workflow. When a machine PXE boots
into Sledgehammer, the inventory or inventory-minimal stage is typically included in the workflow
sequence. The stage runs drpcli gohai on the machine, applies the JQ field extraction rules from
inventory/collect, and writes the results back to the machine's inventory/data parameter via the
DRP API.
The inventory/flatten parameter (boolean) controls whether individual inventory fields are also
written back as top-level machine parameters. When flattening is enabled, fields like inventory/RAM
and inventory/CPUs become directly addressable parameters, which is useful for classification rules.
Querying Inventory Data¶
Inventory data is stored in the inventory/data parameter on each machine and can be queried via
drpcli:
# Show all inventory data for a machine
drpcli machines get <machine-uuid> param inventory/data
# List all machines with their RAM values (when flattening is enabled)
drpcli machines list | jq '.[] | {Name: .Name, RAM: .Params["inventory/RAM"]}'
# Find machines with more than 128 GB RAM
drpcli machines list | jq '[.[] | select(.Params["inventory/RAM"] > 131072) | {Name, UUID: .Uuid}]'
Inventory and Machine Objects¶
Inventory data is attached to the machine object as parameters, not as a separate inventory object. This means inventory travels with the machine throughout its lifecycle and is visible wherever the machine's parameters are visible. When a machine is decommissioned and its machine record deleted, the inventory data is removed as well. To preserve inventory history across decommission cycles, use the auditor or event-router plugin to capture inventory snapshots as audit events before deletion.
Compliance Checking¶
The inventory/check parameter accepts a map of field names to regular expressions. The inventory
stage evaluates each check against the collected data and fails the job if any check does not pass.
This allows operators to enforce hardware baseline requirements (e.g., minimum RAM, required NIC
count) as part of the discovery workflow before a machine proceeds to provisioning.