Add playbook to pre-pull images

[ehelms]

Pre-pulling the images isn't necessary, but can help differentiate the runtime of the actual installer part vs. image pull.

[ekohl]

This makes me think: could we build on this to also build the container images locally? Out of scope for this PR, but it made me think.

[ekohl]

Test failure looks unrelated.

[ehelms]

This makes me think: could we build on this to also build the container images locally? Out of scope for this PR, but it made me think.

I agree, I have some thoughts there and this could be a useful debugging option.

[ehelms]

Test failure looks unrelated.

Yea... this failure keeps popping up and is intermittent. I am going to see if I can figure out why.

[ekohl]

I agree, I have some thoughts there and this could be a useful debugging option.

There is podman image scp perhaps (at least in CI) we should build all containers locally, push them into the managed VM and then continue with the next steps.

[ekohl]

Thinking more: we have podman_image in various roles so you could clearly see when that fails, but systemd will pull on start up anyway and this separate step makes it redundant. Should we drop those instructions from the roles?

Should we also document this in README to recommend users to run it as well?

[ehelms]

Thinking more: we have podman_image in various roles so you could clearly see when that fails, but systemd will pull on start up anyway and this separate step makes it redundant. Should we drop those instructions from the roles?

I am not sure yet, and I think this should depend on our workflow strategy and update strategy. For example, do we want to treat pre-pulling as an optimization or a hard requirement? Do we want a fall back mechanism? How should we expect image updates to happen?

I would guess for updates, like we do today, we want to control and orchestrate that and not leave it up to the whims of a systemd service.