Reference on Corium

Comparison

Mon, 01 Jan 0001 00:00:00 +0000

An honest comparison. If one of these fits you better, use it — that is a better outcome than adopting Corium and regretting it.

Feature support

Mon, 01 Jan 0001 00:00:00 +0000

What Corium models, what it passes through, and what it deliberately does not do.

Configuration

Mon, 01 Jan 0001 00:00:00 +0000

What the configuration file contains, where it comes from, and what Corium does with it.

cctl

Mon, 01 Jan 0001 00:00:00 +0000

cctl manages Corium nodes: it reads their state, drives their upgrades, and decides which of them will obey you.

ADR 1 — Base image

Mon, 01 Jan 0001 00:00:00 +0000

Status: accepted

Context

Corium needs an immutable base in the CoreOS/OSTree lineage, and exposes cloud-init as its configuration surface.

ADR 2 — Root filesystem

Mon, 01 Jan 0001 00:00:00 +0000

Status: accepted

Context

fedora-bootc ships an empty /usr/lib/bootc/install/, so the root filesystem type is undecided. Every tool that installs the image needs it: bootc-image-builder fails with missing required info: DefaultRootFs.

ADR 3 — Software RAID scope

Mon, 01 Jan 0001 00:00:00 +0000

Status: accepted

Context

Issue #5 asked for a way to declare a software RAID array from the corium: block, with the explicit caveat that it should only be added if it earns its place over a plain cloud-init disk setup.

ADR 4 — Management API

Mon, 01 Jan 0001 00:00:00 +0000

Status: accepted

Context

Issue #2 asks for an API to manage the operating system. The discussion on it converged quickly on the two things worth having first — reading a node’s state and driving its upgrade — and just as quickly on the two questions that actually decide the design: what such an API is allowed to do, and how a node learns which operator to obey.

ADR 5 — SSH access over the API

Mon, 01 Jan 0001 00:00:00 +0000

Status: accepted

Context

ADR 4 made the management API deliberately shell-less. It reads a node’s state, drives its upgrade, and moves it through its lifecycle — and it hands out no shell, because a shell over an immutable system grants root to change things that will not persist, and because a pairing code over the console is a better answer to “how does a node learn whom to obey” than a key baked into cloud-init. SSH was the thing the API replaced, and ADR 4 named it as such.

ADR 6 — Host WireGuard overlay

Mon, 01 Jan 0001 00:00:00 +0000

Status: accepted

Context

Issue #7 asks for a way to declare a WireGuard interface on the node itself, from the corium: block, so that nodes across sites or providers can form one cluster over an encrypted overlay. It carries the same caveat issue #5 did for RAID: only add it if it earns its place over a plain cloud-init WireGuard setup. Decision 9 in AGENTS.md is the standing rule behind that caveat — every abstraction has an escape hatch, and write_files plus runcmd are always there — so the burden is on the field to justify itself, not on the escape hatch to justify its absence.