RSSAmplifier

javatask.dev · Jun 5, 2026

Part 5: Quadlet Comes for Free

0
Sign in to vote or save

Andrii Melashchenko · javatask.dev

What you need to know: the payoff of getting packaging right in Part 3 and Part 4 is that a new runtime drops in for almost nothing. Quadlet runs a container as a native systemd service — no Kubernetes, no daemon — on devices that can afford neither. Adding it changes almost nothing for the app developer, the registry, or the fleet manager — one schema-additive patch aside — only the device gains a capability. That’s the “for free” this series has been building toward.

Quadlet, and Why the Constrained OT Edge Needs It#

Quadlet turns a .container unit file into a native systemd service at boot, so the container inherits everything systemd already does for every other service — restart on failure, dependency ordering, journald logging, socket activation — without a daemon process. Podman runs fork-exec; systemd is the only thing that stays resident, and it was already there.

That’s what an unattended device needs: nobody is at a PLC-adjacent box at 3 a.m. to restart a crashed container, and Kubernetes buys the same net at a cost these devices can’t pay. Quadlet is production-ready today; the gap is that a Margo-compliant Workload and Fleet Manager (WFM) has no standard way to deploy it. A device with systemd and a Quadlet-capable Podman can’t be managed by Margo — not for lack of capability, but because the specification has nowhere to point at it.

SUP-02 closes that gap: a proposal I’ve put up for Margo Technical Working Group review, currently at stage P2, with a formal Feature Project still required before a Phase-3 vote. Nothing here is adopted spec text yet.

Margo pipeline from app developer to registry to WFM to device, with the app-developer and registry stages greyed and labeled UNCHANGED, the WFM stage labeled ONE SCHEMA PATCH, and only the device node highlighted and labeled LEARNS SYSTEMD/QUADLET.

Figure 1 — Everything upstream of the device stays the same, except one schema-additive patch to the WFM.

Additive Only#

SUP-02 depends on SUP-01 — it reuses the OCI mandate, media-type table, and type slot regex that Part 4 established for Compose, rather than inventing a parallel mechanism. The type discriminator in application-description.linkml.yaml expands from ^(helm|compose)$ to ^(helm|compose|quadlet)$ — additive, so every existing ApplicationDescription still validates. Two new schema classes, QuadletDeploymentProfile and QuadletComponent, sit alongside ComposeDeploymentProfile and ComposeComponent; no existing class is modified. A WFM that doesn’t understand quadlet never selects it; a non-capable device never receives it.

What SUP-02 does not touch is Quadlet unit-file content — systemd unit semantics, network/volume definitions, socket activation — governed by the Quadlet unit file specification. Margo’s lane is packaging, not unit authoring — the same division Parts 3–4 drew around Compose file content.

Only the Device Changes#

The publishing workflow is the same oras push shape that Part 4 used for Compose, with two new media types registered under the application/vnd.org.margo.component.* namespace:

oras push registry.example.com/org/myapp:1.0.0 \
  --artifact-type application/vnd.org.margo.component.quadlet+json \
  myapp-1.0.0-quadlet.tar.gz:application/vnd.org.margo.component.quadlet.tar+gzip

The ApplicationDescription references it by repository and revision — the fields Compose and Helm already use — under the same directory-layout and integrity rules that Part 4 walked for Compose. The only difference is .container/.network/.volume files (Quadlet also defines .image, .build, .pod) instead of compose.yaml. The registry stores it like any other OCI artifact; the WFM’s processing logic is unchanged. The one schema-additive touch is a companion patch to desired-state.linkml.yaml, adding QuadletDeploymentProfile and QuadletComponent so a WFM can generate a schema-valid desired-state document — narrow and mechanical, not new logic.

The device carries the requirement: it must already be capable of processing Quadlet unit files — Podman with systemd integration — before it can receive a quadlet profile. SUP-02 explicitly states this is out of scope: provisioning that runtime is a deployment prerequisite, not a WFM job.

One oras push command feeding a single OCI artifact, with three labeled component types — Helm, Compose, Quadlet — branching from it, and a shared content-addressable digest icon marked FREE across all three.

Figure 2 — One publishing command, one integrity mechanism, three runtimes.

Why Quadlet, Not the Alternatives#

SUP-02 rejected two other paths. Plain Compose on Podman gives container execution without systemd lifecycle integration — no restart-on-failure, no ordering, no journald, no socket activation. On an unattended device, that’s the difference between a crashed service staying crashed and one that recovers itself. For Kubernetes, a minimal K3s install needs roughly 500 MB of RAM and a persistent control plane; many of the PLCs and embedded controllers this SUP targets have only 256–512 MB total, leaving no room for the workload. Quadlet asks only for systemd and a Quadlet-capable Podman, both already shipping on modern industrial Linux.

SUP-02 Formalizes an Earlier Proposal#

This isn’t a new idea. Part 4 of “Intro into Podman Quadlet” sketched a quadlet.v1 profile months before this series existed. SUP-02 is that same proposal, now written against the OCI pattern that SUP-00 and SUP-01 established — the same provider and capability-advertisement gap, now a formal schema diff with media types and a conformance table instead of a sketch.

What Five Parts Bought#

Helm arrived at an OCI registry contract by convention. Compose didn’t have one, and Part 2 showed three ways that gap breaks in production. Parts 3–4 closed it by applying the same five-element pattern Helm already runs on, and the payoff shows up here: a third component type is now a media-type registration and a schema class, not a new publishing model. One oras push, one digest, three runtimes — the only thing that changed on the way to Quadlet was what the device already knew how to run.

Part 4 — Fixing Compose | Part 3 — The Five Elements | The earlier proposal SUP-02 formalizes | Quadlet internals | .systems companion


Andrii Melashchenko is a Senior Principal Architect at Belden and an active contributor to the Margo specification. SUP-02 is his own open proposal at stage P2, taking nothing away from Helm or Compose. Protocol details are drawn from the Margo Pre-Draft specification and may change as the specification matures.

Read the original on javatask.dev

Comments

Nothing yet. Say the first thing.

    Sign in to join the conversation.