Crate draupnir 

Draupnir — the nordisk boot / provisioning library

Draupnir is the low-level engine that fires up a runtime instance from a single BootSpec, across three backends, and drives its power lifecycle:

• kvm — a KVM/appliance VM, booted by driving tunnr’s tunnr_vm::boot_test(BootSpec) -> BootHandle primitive (feature backend-tunnr). Draupnir does not reimplement VM boot — it wires the Boot trait against tunnr.
• container — an OCI container, brought up over a container runtime.
• redfish — bare metal, provisioned out-of-band through a BMC’s Redfish REST API (iLO / iDRAC / OpenBMC): insert a virtual-media ISO, set the one-time boot override to that media, power the node on. This is the capability Draupnir uniquely owns.

Where Draupnir sits

Draupnir is the shared low-level boot lib. Two high-level consumers depend on it directly and neither duplicates its boot code:

• jera (edda’s job handler) → depends on Draupnir for job instances (process | VM | container). jera stays thin: just job policy.
• Skidbladnir (service/systemd, airgap, orchestration) → depends on Draupnir for service instances.

Draupnir itself knows nothing about jobs or services; it just fires up and controls instances. For its KVM backend it calls down into tunnr.

  jera ─────────┐
                ├──▶ Draupnir ──▶ { tunnr (KVM) | OCI runtime | Redfish BMC }
  Skidbladnir ──┘

The mythological nod

Draupnir is Odin’s gold ring that drips eight identical copies of itself every ninth night. Here that is a natural extension, not the core: booting a fleet of identical machines from one ISO — plan_fleet fans one BootSpec out into N identical specs (bare-metal fleet provisioning via Redfish). The core is one library, three boot backends.

Modules

container

Container backend — fire up an OCI container instance (e.g. a redis service) over a container runtime.

kvm

KVM backend — fire up an appliance VM by driving tunnr.

redfish

Redfish backend — provision bare metal out-of-band through a BMC.

Structs

BmcEndpoint

A BMC (baseboard management controller) endpoint — the out-of-band Redfish service on a bare-metal node (iLO / iDRAC / OpenBMC).

BootSpec

A self-contained boot request. One shape fires up any backend; the backend selects the driver and [validate] enforces that the image (and, for Redfish, the bmc) match.

CloudInit

cloud-init NoCloud provisioning for a KVM appliance boot: the user-data (and optional meta-data) authored into a small FAT seed image (volume label cidata) the guest’s cloud-init picks up at first boot.

Machine

A booted (or booting) instance handle — what a Boot::boot returns and what Lifecycle acts on.

Enums

Backend

Which runtime a BootSpec targets.

BootTarget

The one-time boot device a Redfish node is overridden to.

Error

Everything that can go wrong firing up or controlling an instance.

ImageSource

The bootable payload — the source an instance is fired up from.

PowerState

The power state of an instance.

Traits

Boot

Fire up an instance from a BootSpec. One trait, three implementations (kvm::KvmBoot, container::ContainerBoot, redfish::RedfishBoot).

Lifecycle

Drive an instance’s power lifecycle after it is fired up.

VirtualMedia

Redfish virtual-media + boot-override control — the out-of-band steps that make a bare-metal node boot our ISO. Only the redfish::RedfishBoot backend implements it; the KVM/container backends have no BMC.

Functions

boot

The unifying entry point — fire up one instance from a BootSpec across whichever backend is handed in. It validates the spec first (so a mismatched image/BMC is rejected before any backend is touched), then delegates to the backend’s Boot::boot. The same spec boots the same image on a kvm::KvmBoot, a container::ContainerBoot, or a redfish::RedfishBoot — one call, three backends.

boot_fleet

Drip a fleet from one image — plan_fleet the spec into n members and boot each through backend, returning a per-member result (a partial fleet is observable: some members may boot while a later one errors).

plan_fleet

The ring drips eight copies — fan one BootSpec out into n identical specs, each with a distinct "{name}-{i}" name (1-based), for booting a fleet of identical machines from one image/ISO.

Type Aliases

Result

Draupnir’s result alias.