Allow Ignition to run shell commands

[Limero]

Feature Request

I want Ignition to overlay packages with rpm-ostree install to install cockpit in addition to my containers that are setup by systemd units.

Because of Ignition's goal to be distro agnostic, a feature to directly allow overlay packages in the config will not be accepted. How about an option to run any shell commands be added instead? That would allow any modifications to be done automatically, without running a separate shell script on first boot.

[bgilbert]

Ignition configs are declarative and shell scripts are not. However, you can use Ignition to write a one-shot systemd unit that has ConditionFirstBoot=true, and that unit can run whatever commands you want.

[fr3aker]

Ignition configs are declarative and shell scripts are not.

I understand the sentiment behind that statement, but it disregards the fact that Ignition simply cannot do many things. Provisioning frameworks such as ansible and chef provide mechanisms for installing packages, manage system services and a lot more.

Yet, Ignition is supposed to be the provisioning tool for coreos but is lacking basic abilities to actually properly provision a host.

Delegating provisioning by hacking a systemd unit is not only counter-intuitive but even completely defeats the purpose of a provisioning tool. There will be no feedback on whether the provisioning was actually successful.

[jlebon]

Delegating provisioning by hacking a systemd unit is not only counter-intuitive but even completely defeats the purpose of a provisioning tool. There will be no feedback on whether the provisioning was actually successful.

You get feedback from systemctl status foobar.service. ;) Using systemd units is actually a lot more powerful than just handing over arbitrary shell scripts. E.g. a huge issue with cloud-init was ordering when scripts actually ran and often bootcmd and runcmd weren't good enough (see e.g. projectatomic/container-storage-setup#77 (comment)). With a systemd service, you can specify exactly when and how you want it to run in the native systemd DSL.

Being able to run completely independent scripts in separate systemd units also makes it easier to debug and follow progress. E.g. OCP helpfully prints this when you log in during installation.

As far as marking provisioning as successful, Ignition itself will fail if it couldn't provision the machine. In the real root, we have some design work going on in coreos/fedora-coreos-tracker#47 to verify that the machine actually came up "successfully", for a user-customizable definition of what successful means.

[cgwalters]

One bridge we could make though is to have an ignition-firstboot-complete.target in the real rootfs, and have hooks for its failure similar to the Ignition process in the initrd. Then users doing custom provisioning in the real root could just make their units required by that target and get integration for free very much as if their code was part of Ignition.