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.

[cgwalters]

Just to followup on this, personally: what I would like to do is push to having Anaconda (and other installers) work in cloud environments - basically it'd move itself to RAM and be able to rewrite the root disk to repartition - think of the whole "first boot" like an initramfs basically.

I think we could put sufficiently slimmed down Anaconda (i.e. just a TUI) into the default cloud images, so nothing else would need to be fetched from the network in the default case. For some cases where we just want to change the filesystem/block setup (e.g. "enable LUKS") we could avoid a reboot into the new kernel even. But for cases where we actually want to pivot/switch into a new system (e.g. bootc, or just swap kernels and filesystem layout), that also is cleanly possible in the same way.

Again the ideas here apply in theory to any classic "installer" of which there are many like debian-installer and opensuse yast etc. - my point is that Ignition has some of this role of "installer" and by going this route we make things cleaner for the OS/distros that care about bare metal and cloud and need to care about non-Ignition systems.