Problem
The plugin is read-only (providers/regions/sites/clusters/nodes, tree, summary). Populating the inventory is done by bin/load-inventory in datum-cloud/infra — a bash script that renders YAML and shells out to datumctl apply --dry-run=server / datumctl apply. datumctl is just a dumb applier there; the loader owns rendering and upsert.
We want the inventory population path to be native datumctl inventory operations, so this plugin is the single front door for loading the inventory — not a bash wrapper around apply.
Scope: inventory population only. Explicitly not fleet management (no assign/cordon/decommission/delete lifecycle, no provisioning). Point-in-time load from declared config, matching the loader's current contract.
What bin/load-inventory does today
- Phases in dependency order:
provider → region → site → cluster → node (networkdevice deferred).
- Renders each kind from declared sources and upserts idempotently.
--dry-run → datumctl apply --dry-run=server; --print → emit manifests, no server contact.
- All kinds cluster-scoped on the platform root (
--platform-wide).
Proposed plugin capability
Add a write/apply path to datumctl inventory, confined to population:
datumctl inventory apply -f <file|-> — idempotent server-side upsert of inventory manifests (Provider/Region/Site/Cluster/Node), typed + validated client-side before apply.
--dry-run=server and a --print/diff equivalent, matching the loader's flags.
- Dependency-ordered apply (parents before children) so a single mixed manifest stream lands cleanly.
- Immutability- and webhook-aware errors surfaced cleanly (immutable
regionRef/siteRef/controlPlaneSiteRef; parent-delete rejection).
Division of labor
- This plugin owns the generic, reusable part: idempotent typed upsert + dry-run of inventory objects.
- infra-specific rendering (parsing
provisioning/region.ipam, provisioning/datum.sites, provisioning/configure-netactuate, and the Omni fleet for clusters/nodes) stays in datum-cloud/infra. After this lands, bin/load-inventory collapses to a renderer that pipes manifests into datumctl inventory apply -f - — the bash apply plumbing and manifest-by-hand templating go away.
Source adapters (read region.ipam / datum.sites / Omni directly) stay infra-side. Plugin only owns apply.
Acceptance
Relates: datum-cloud/infra#2675 (original load), datum-cloud/datumctl#211.
Problem
The plugin is read-only (
providers/regions/sites/clusters/nodes,tree,summary). Populating the inventory is done bybin/load-inventoryin datum-cloud/infra — a bash script that renders YAML and shells out todatumctl apply --dry-run=server/datumctl apply. datumctl is just a dumb applier there; the loader owns rendering and upsert.We want the inventory population path to be native
datumctl inventoryoperations, so this plugin is the single front door for loading the inventory — not a bash wrapper aroundapply.Scope: inventory population only. Explicitly not fleet management (no assign/cordon/decommission/delete lifecycle, no provisioning). Point-in-time load from declared config, matching the loader's current contract.
What bin/load-inventory does today
provider → region → site → cluster → node(networkdevice deferred).--dry-run→datumctl apply --dry-run=server;--print→ emit manifests, no server contact.--platform-wide).Proposed plugin capability
Add a write/apply path to
datumctl inventory, confined to population:datumctl inventory apply -f <file|->— idempotent server-side upsert of inventory manifests (Provider/Region/Site/Cluster/Node), typed + validated client-side before apply.--dry-run=serverand a--print/diff equivalent, matching the loader's flags.regionRef/siteRef/controlPlaneSiteRef; parent-delete rejection).Division of labor
provisioning/region.ipam,provisioning/datum.sites,provisioning/configure-netactuate, and the Omni fleet for clusters/nodes) stays in datum-cloud/infra. After this lands,bin/load-inventorycollapses to a renderer that pipes manifests intodatumctl inventory apply -f -— the bashapplyplumbing and manifest-by-hand templating go away.Source adapters (read region.ipam / datum.sites / Omni directly) stay infra-side. Plugin only owns apply.
Acceptance
datumctl inventory apply -f fleet.yamlupserts Provider/Region/Site/Cluster/Node idempotently (re-run = no change).--dry-run=servervalidates without persisting; a print/diff mode exists.bin/load-inventoryreduced to rendering +datumctl inventory apply -f -; no directdatumctl applyof hand-rendered inventory YAML.Relates: datum-cloud/infra#2675 (original load), datum-cloud/datumctl#211.