sugar for provisioning via container

[cgwalters]

One thing I think would be interesting is sugar like this:

provisioncontainer: quay.io/myuser/setup@sha256:shashasha

This would expand into a systemd unit which ran podman under ConditionFirstBoot=yes something like this: podman run --rm quay.io/myuser/setup --privileged -v /:/host

And we could give some examples of using "first boot containers" like this that can do completely arbitrary things, say use an Ansible playbook pointing at the host, or use Ruby scripts - whatever.

This isn't hard to write manually but it's also not entirely obvious, and we'd be encouraging the pattern of containerization even for early boot.

[ajeddeloh]

I think it would be good to make this more general for launching containers in general, though that require adding something like runtime-args for things --volume and --privileged. Maybe something like:

containers:
 - image: `quay.io/example/example:v2`
   runtime: docker # docker | podman, podman default. docker adds the correct unit deps for docker.socket
   runtime-args: [ "--net=host" ]
   provisioning: true # adds `--privileged`, `-v /:host` to runtimeargs, ConditionFirstBoot=yes to the unit
   dropins:
     - <systemd drop ins for the unit>

This would cut down the boilerplate for units in general basically killing two birds with one stone

[jlebon]

This came up in the FCOS Hands-On Lab today. The podman generate systemd command already contains code for how to provision containers via systemd units. Would be great to leverage this. Some ideas that came up:

• have fcct call out to podman: not great, embeds the assumption that podman is installed.
• have a more generic "put the output of this command here" helper: user's responsibility to make sure they have podman installed when converting, full control over the podman flags, could be used with many other things as well, but less pleasant to use than declarative sugar.
• have fcct generate a systemd generator which runs the podman command to create the systemd service: slightly contrived, though no local podman required and uses the podman of the target FCOS version.

[bgilbert]

Looking at the output of podman generate systemd, I'm not seeing anything sufficiently complex to be worth delegating to another tool. Any reason we shouldn't just generate the unit ourselves?

[jlebon]

Related: https://github.com/containers/quadlet/

Maybe instead of also implementing our own generators, we just support quadlet configs, e.g.:

containers:
  - name: minimal
    quadlet: |
      [Unit]
      Description=A minimal container

      [Container]
      Image=centos
      Exec=sleep 60

      [Service]
      Restart=always

which converts into a file at /etc/containers/systemd/minimal.container. (Obviously this implies https://github.com/coreos/fedora-coreos-tracker/issues/998.)