Thread by @ahrkrak

Some Linux distros (e.g. @FedoraCoreOS and @flatcar) use Ignition instead of cloud-init for machine initialization.

⚡️What is ignition, and how is it different from cloud-init?

Kudos to @RedHat for the clear docs (see link at end), summarized in this 🧵(1/14)

Ignition runs from an initial RAM disk that is separate from the system you are installing to. Because of that, Ignition can repartition disks, set up file systems, and perform other changes to the machine’s permanent file system. (2/14)

In contrast, cloud-init runs as part of a machine’s init system when the system boots, so making foundational changes to things like disk partitions can't be done as easily; it's also difficult to reconfigure the boot process while in the middle of the node’s boot process. (3/14)

💡 ** Ignition is meant to initialize systems, not change existing systems. ** (4/14)

Ignition implements declarative configuration. It checks that all partitions, files, services & other items are in place before the new machine starts. It then makes the changes, like copying files to disk that are necessary for the machine to meet specified configuration. (5/14)

After Ignition finishes configuring a machine, the kernel keeps running but discards the initial RAM disk and pivots to the installed system on disk.

All of the new system services and other features start without requiring a system reboot. (6/14)

Because Ignition confirms that all new machines meet the declared configuration, you cannot have a partially-configured machine.

If setup fails, the initialization process does not finish, and Ignition does not start the new machine. (7/14)

👉 ** Your cluster will never contain partially-configured machines. ** (8/14)

If Ignition cannot complete, the machine is not added to the cluster. You must add a new machine instead. This prevents the difficult case of debugging a machine when the results of a failed configuration task are not known until something that depended on it later fails. (9/14)

If there is a problem with an Ignition config that causes the setup of a machine to fail, Ignition will not try to use the same config to set up another machine. (10/14)

If you have multiple Ignition config files, you get a union of that set of configs. Because Ignition is declarative, conflicts between the configs could cause Ignition to fail to set up the machine. The order of information in those files doesn’t matter. (11/14)

If you have multiple Ignition config files, Ignition will sort and implement each setting in ways that make the most sense.

For example, if a file needs a directory several levels deep, if another file needs a directory along that path, the later file is created first. (12/14)

Because Ignition can start with a completely empty hard disk, it can do something cloud-init can’t do: set up systems on bare metal from scratch (using features such as PXE boot). (13/14)

The above is based on this excellent doc:
access.redhat.com/documentation/…

See also the upstream Ignition repo: github.com/coreos/ignition
(14/14)