Add machine init --run-playbook

[jakecorrenti]

Allow the user to provide an Ansible playbook file on init which will then be run on first boot.

This is dependent on containers/podman-machine-os#68 and containers/podman-machine-wsl-os#11 getting merged.

Does this PR introduce a user-facing change?

Adds the `--run-playbook` flag to `podman machine init`

[jakecorrenti]

cc @baude

[baude]

/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: baude, jakecorrenti

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [baude]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Luap99]

Cross linking containers/podman-machine-os#68 (comment)

Here this seems quite limiting in what it would do. AFAICT ansible playbooks can consist of many different files that are included, the directory structure can be complex, see https://docs.ansible.com/ansible/2.8/user_guide/playbooks_best_practices.html#directory-layout

As such I really don't see how this would help many users with complex things that have more than a single file. Would it not be much better to require the user to have ansible installed on the host and run it from there?

[baude]

no, this is quite useful. it can be a single file and in this case, it is perfectly OK to be ... this, in conjunction with something like a podman machine cp and custom ignition files should solve the ongoing complaints from users about customizing machine images when these choose to simply not rebuild their own.

[Luap99]

it can be a single file and in this case, it is perfectly OK to be

Sure it can be a single file. But this restricts the purpose AFAICT and I bet we just get more people asking to allow multiple files and whatever else ansible can do. Thus I am just not sure if it makes sense to go with a design that we cannot easily extend later.

Also isn't this just super racy? We simply start a playbook but never wait for it to be done which means whatever config should be applied may not be ready thus causing hard to diagnose issues. Also unless someone knows to ssh into the machine and knows the unit name they will not be able to get the output in case of failures.

And then this currently says it runs on first boot but the unit would be run on every boot unless I am missing something.

[jakecorrenti]

What am I missing here? I did make docs and I made sure the new flag was added to the manpage

[l0rd]

I think this won't work on Windows when using WSL until we add ansible in the image used in that case.

More generally, with this PR, we are adding an implicit dependency between podman and the machine image: if ansible is not pre-installed in the machine image (i.e., it's a custom one), --run-playbook doesn't work. I don't know how much of a problem custom images are, but Ansible is not a " small " pre-requisite (in terms of size and its dependencies). If customers habitually use custom images, having a custom image guideline that mentions Ansible would be helpful.

Also, playbooks with a local path won't work (as mentioned in the man page). But this can be worked around if paths in the playbook are converted as it's currently done for volumes and additional build contexts.

[baude]

@jakecorrenti please file a PR to add ansible to the machine image.

[jakecorrenti]

I think this won't work on Windows when using WSL until we add ansible in the image used in that case.

I made a PR to fix that: containers/podman-machine-wsl-os#11. I don't have a way to test it, however.

More generally, with this PR, we are adding an implicit dependency between podman and the machine image: if ansible is not pre-installed in the machine image (i.e., it's a custom one), --run-playbook doesn't work. I don't know how much of a problem custom images are, but Ansible is not a " small " pre-requisite (in terms of size and its dependencies). If customers habitually use custom images, having a custom image guideline that mentions Ansible would be helpful.

Would it be enough to add in the manpage that custom images are required to have Ansible added? Or would you rather have something completely separate.

Also, playbooks with a local path won't work (as mentioned in the man page). But this can be worked around if paths in the playbook are converted as it's currently done for volumes and additional build contexts.

[baude]

Would it be enough to add in the manpage that custom images are required to have Ansible added? Or would you rather have something completely separate.

I think something in the man page like that says this requires ansible be present in the image which is default is a fair thing to do.

But more importantly, lets add a statement to --image that basically says we only support the images we provide. wdyt ?

[jakecorrenti]

Would it be enough to add in the manpage that custom images are required to have Ansible added? Or would you rather have something completely separate.

I think something in the man page like that says this requires ansible be present in the image which is default is a fair thing to do.

But more importantly, lets add a statement to --image that basically says we only support the images we provide. wdyt ?

I think that sounds like a good idea

[packit-as-a-service]

Cockpit tests failed for commit ade327b. @martinpitt, @jelly, @mvollmer please check.

[Luap99]

@jakecorrenti FYI you should rebase and in general try to always rebase on each push to pick up the latest changes such as CI fixes, the machine test timeout was bumped to 45 mins in the meantime which should make it more likely that the test pass.