QTM-1002 - Inventory Before Orchestration (Hardware manifests vs. CMDB bloat)

Living Document Notice
Published 2026-09-11. The evolving architecture, revisions, and connected notes for this dispatch live in the Stax Digital Garden.

Inventory Before Orchestration (Hardware manifests vs. CMDB bloat)

Summary

Enterprise configuration management databases introduce heavy relational schemas, external network dependencies, and agent memory footprints that overwhelm modest infrastructure. Maintaining physical hardware baselines in version-controlled declarative manifests establishes clear operational state without runtime database overhead.

The Operational Penalty of Centralized CMDBs

Enterprise configuration management databases (CMDBs) attempt to capture infrastructure state dynamically through continuous agent polling and automated network discovery sweeps. In practice, this architecture imposes high system costs on modest infrastructure fleets. Running Java-based discovery agents or continuous Python monitoring processes consumes hundreds of megabytes of resident memory on nodes with limited total capacity.

Dynamic discovery systems also introduce state ambiguity. When network partitions occur or discovery daemons encounter local timeout errors, CMDB records desynchronize from actual node states. Operators are left debugging whether a missing network interface reflects a hardware failure or a transient discovery timeout. Relational CMDB schemas introduce dozens of foreign-key dependencies to express simple physical properties such as PCIe lane assignments or RAM module slots.

Quartermaster rejects dynamic database inventories in favor of static, version-controlled manifests stored directly in the repository alongside operational code. A physical server or virtual private server does not change its motherboard, CPU architecture, or PCIe topology without physical human intervention or explicit hypervisor reconfiguration. Capturing physical hardware baselines in plain YAML files treats machine hardware as an immutable operational contract.

Flat Manifest Topology

The Quartermaster hardware manifest resides on each managed node at /etc/quartermaster/hardware.yaml and is tracked in Git. The file documents the physical attributes of the machine down to the memory bank and block device serial number.

version: "1.0"
schema: "quartermaster/hardware"
node_id: "qtm-node-lon-01"
chassis:
  form_factor: "1u-rack"
  serial_number: "SYS-5019D-FN8TP-01928"
  management_ip: "10.100.0.12"
motherboard:
  vendor: "Supermicro"
  model: "X11SDV-8C-TP8F"
  bios_version: "2.1b"
cpu:
  sockets: 1
  model: "Intel Xeon D-2146NT"
  cores: 8
  threads: 16
  base_clock_mhz: 2300
memory:
  total_mb: 32768
  ecc: true
  slots_total: 4
  slots_populated: 2
  modules:
    - slot: "DIMMA1"
      size_mb: 16384
      type: "DDR4-2666-RDIMM"
    - slot: "DIMMB1"
      size_mb: 16384
      type: "DDR4-2666-RDIMM"
storage:
  controllers:
    - id: "nvme-ctrl-0"
      interface: "PCIe 3.0 x4"
      devices:
        - device_node: "/dev/nvme0n1"
          model: "Samsung SSD 980 PRO 1TB"
          serial: "S5GXNF0T104928"
          capacity_bytes: 1000204886016
          endurance_tbw: 600
network:
  interfaces:
    - name: "eth0"
      pci_bus: "0000:03:00.0"
      mac_address: "ac:1f:6b:88:21:40"
      link_speed_mbps: 10000
      driver: "ixgbe"

Because the hardware manifest lives in version control, any hardware change requires a committed diff. If a technician replaces a degraded memory module or installs a secondary NVMe drive, the Git commit log documents the exact operational context of that modification.

Operational Comparison: Static Manifest vs. Dynamic CMDB

Choosing between a declarative repository manifest and a centralized dynamic CMDB defines the failure modes of the operations stack.

System Dimension	Quartermaster Flat Manifest	Enterprise CMDB
Primary Storage Engine	Plain YAML files in Git	Relational database (PostgreSQL, Oracle)
Runtime Memory Consumption	0 MB background overhead	250 MB to 600 MB per discovery agent
Network Dependency	None for local node operations	Constant bidirectional network connectivity
Audit Trail	Git commit history and GPG signatures	Database write-ahead logs and application audit tables
Synchronization Model	Explicit operator commit	Background asynchronous polling sweeps
Recovery Usability	Readable via standard POSIX coreutils	Requires functioning database connection

Hardware Baseline Verification

To verify that the declared manifest accurately reflects host state, Quartermaster executes an audit check using standard Linux diagnostic tools. The script compares hardware counters extracted from dmidecode and lsblk against values defined in /etc/quartermaster/hardware.yaml.

#!/bin/sh
set -eu
 
MANIFEST="/etc/quartermaster/hardware.yaml"
 
if [ ! -f "$MANIFEST" ]; then
  echo "CRITICAL: Hardware manifest $MANIFEST missing" >&2
  exit 1
fi
 
# Extract physical CPU core count from kernel procfs
ACTUAL_CORES=$(grep -c '^processor' /proc/cpuinfo)
DECLARED_CORES=$(awk -F': ' '/threads:/ {print $2}' "$MANIFEST" | tr -d ' "')
 
if [ "$ACTUAL_CORES" -ne "$DECLARED_CORES" ]; then
  echo "MISMATCH: CPU thread count (kernel: $ACTUAL_CORES, manifest: $DECLARED_CORES)" >&2
  exit 2
fi
 
# Validate NVMe block device presence
for DEV in $(awk -F': ' '/device_node:/ {print $2}' "$MANIFEST" | tr -d ' "'); do
  if [ ! -b "$DEV" ]; then
    echo "CRITICAL: Block device $DEV specified in manifest not found on system bus" >&2
    exit 3
  fi
done
 
echo "AUDIT OK: Hardware matches declared manifest $MANIFEST"

---

• Directus Target: quartermaster
• Garden Source Reference: MOC - Fleet Operations
• Garden Source Reference: MOC - Bosun PKM Tools
• Garden Source Reference: QTM-1002 - Inventory Before Orchestration (Hardware manifests vs. CMDB bloat)