Decisions on Corium

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. Its configuration surface is cloud-init.

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 it does not set the type of the root filesystem. Every tool that installs the image needs this type. Without 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. It added an explicit condition: add the feature only if it is better than 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 agreed quickly on the two features to build first: reading the state of a node and driving its upgrade. It also agreed quickly on the two questions that decide the design. What is such an API allowed to do? How does a node learn 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 shell-less on purpose. The API reads the state of a node, drives its upgrade, and moves it through its lifecycle. It gives no shell, for two reasons. First, a shell over an immutable system grants root access to change things that will not persist. Second, to the question “how does a node learn whom to obey”, a pairing code over the console is a better answer than a key baked into cloud-init. The API replaced SSH, and ADR 4 said so.

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. With it, nodes across sites or providers can form one cluster over an encrypted overlay (a private network that runs on top of the public one). The issue carries the same caveat that issue #5 carried for RAID: add the feature only if it is better than 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 available. So the field must justify itself. The escape hatch does not have to justify its absence.

ADR 7 — ZFS on data disks

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

Status: accepted

Context

Some nodes keep local state on their data disks, for example a persistent-volume provisioner, an image or build cache, or scratch space. These nodes want what ZFS gives and raid[] does not: end-to-end checksums, transparent compression, and snapshots. Issue asked whether Corium could put ZFS on those data disks.

ADR 8 — Day-two reconcile

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

Status: accepted

Context

Corium reads a node’s configuration once, at first boot, and then stops. Decision 11 makes this a deliberate position and not an accident: Corium provisions nodes and does not manage them. ADR 4 states the rule under it: a node answers the question of its configuration before it is a node. cctl apply, and the POST /v1/config behind it, writes /etc/corium/config.yaml (first in the source chain, decision 6). As soon as a node has bootstrapped, it refuses the request:

ADR 9 — Artefact builder

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

Status: proposed

Context

Issue #11 points out two facts. Every installable artefact that Corium produces (the qcow2, the raw disk and the installer ISO) goes through bootc-image-builder. And upstream archived that project on 2026-06-18. These are the facts, checked against the registries and the upstream source, not against the announcement:

ADR 10 — Kubernetes version axis

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

Status: accepted

Amends decisions 3, 4 and 5, and adds decision 16.