Skip to content

Native datumctl inventory apply to replace bin/load-inventory #2

@ecv

Description

@ecv

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-rundatumctl 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

  • datumctl inventory apply -f fleet.yaml upserts Provider/Region/Site/Cluster/Node idempotently (re-run = no change).
  • --dry-run=server validates without persisting; a print/diff mode exists.
  • Mixed manifests apply in dependency order.
  • bin/load-inventory reduced to rendering + datumctl inventory apply -f -; no direct datumctl apply of hand-rendered inventory YAML.

Relates: datum-cloud/infra#2675 (original load), datum-cloud/datumctl#211.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions