Thoughts on Ignition past and present

[cgwalters]

I was asked for my thoughts on Ignition. Background: I've worked many years on the Fedora CoreOS and derivatives and on OpenShift 4 and the MCO. I also have extensive experience with Anaconda and other related tools.

Ignition has two major sub-parts storage/disks (partitioning) and systemd/files (writing files into the rootfs).

Thoughts on storage/disks (and related keys that operate on block devices or filesystems)

The rationale behind Ignition doing storage in the way it does is really strong, and it's as relevant in 2025 as it was the day Ignition was released (almost 10 years ago!). I think it's especially cool that one can use Ignition to do LUKS (which means it works in IaaS environments like KubeVirt, GCP, AWS etc.).

There is a looming issue around the intersection of Ignition's storage and systemd-repart - but that's true also of other tooling that does partitioning, like Kickstart and many others.

Thoughts on systemd+files

The systemd key is mostly sugar for writing raw files. It is this part of Ignition that I would say is the weakest and most painful for users. The biggest problem is lack of support for "day 2" reconfiguration, which we implemented in a less than beautiful way in the OpenShift MCO (related blog entry).

One continual confusion point for people is thinking that Ignition is the only way to write files on a system using it, but that isn't true. Because of this lack of reconfiguration support it can often make sense to only use Ignition for "bootstrap" configuration, and then use something else for "day 2".

The tricky thing is "how does day 2" work strongly intersects with how operating system upgrades work. Sometimes, one wants to strongly couple OS upgrades and config updates. And that's where the default model of bootc shines.

If you're doing "day 2" config changes at the base OS level, you also want rollback support.

However, we also want to support decoupled config.

A strongly related issue is that commonly system operators want to write separate configs and think about them independently. While today one can use Butane and write/version sub-sections of Ignition in separate files, it still gets flattened into one big single JSON file and all sense of identity for those individual components is lost.

Recently systemd introduced confext which aims to help with both of those. confext (and sysext) are their own large sub-world I could write about here.

The bit related to this that's on the bootc roadmap is configmap support, which would aim to have a Kubernetes-style API that also decouples the OS and config, and I think that would be hugely beneficial for systems using bootc and Ignition (e.g. FCOS derivatives) as really a vast selection of the base OS configuration could live there and be "day 2" updatable in a sane way.