make buildah available on MPC VMs

[brianwcook]

This PR makes buildah available on the VM image in addition to podman to support the development of buildpack builder image task so that buildpack tools will work properly.

[cmoulliard]

I did a couple of tests and was able to replace the buildah commands able to create a container and mount it using podman

container=$(podman create ${IMAGE})
podman unshare
podman mount $container | tee ${HOME}/shared/container_path

I suggest that you wait till we have finished the tests we are doing to build "buildpack" artifacts before to merge or close this PR

[ifireball]

I'd rather we make the actual pipeline task worry about this kind of detail - instead of adding more and more stuff to the provision task.

I suppose we also have a local version of the task - could we run the same container that the local version runs on the cluster - on the VM? I suppose that would already contain all the dependencies we would need

[cmoulliard]

I'd rather we make the actual pipeline task worry about this kind of detail - instead of adding more and more stuff to the provision task.

I agree with you but until now a user is not allowed to add additional software within the VM created. So what is then the strategy that you propose in this case ?

[ifireball]

I'd rather we make the actual pipeline task worry about this kind of detail - instead of adding more and more stuff to the provision task.

I agree with you but until now a user is not allowed to add additional software within the VM created. So what is then the strategy that you propose in this case ?

Perhaps run a container with the required software on the VM.

[cmoulliard]

Perhaps run a container with the required software on the VM.

This idea is interesting but we will have, for some applications, an issue when they will need to access the DOCKER_HOST (unix socket, etc) from the container

[ifireball]

Perhaps run a container with the required software on the VM.

This idea is interesting but we will have, for some applications, an issue when they will need to access the DOCKER_HOST (unix socket, etc) from the container

If you were doing a similar task inside the cluster - how would you manage it?

[cmoulliard]

If you were doing a similar task inside the cluster - how would you manage it?

Until now, we do this within the remote VM where we execute a bash script

https://github.com/redhat-buildpacks/builder-ubi-base/blob/463234816d380e4e2e1882af824a9dbf976cb7b8/.tekton/pipelinerun-builder-ubi-base.yaml#L267-L275

systemctl --user start podman.socket
export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock

pack builder create ${IMAGE} --config builder.toml ${PACK_ARGS}

[ifireball]

If you were doing a similar task inside the cluster - how would you manage it?

Until now, we do this within the remote VM where we execute a bash script

https://github.com/redhat-buildpacks/builder-ubi-base/blob/463234816d380e4e2e1882af824a9dbf976cb7b8/.tekton/pipelinerun-builder-ubi-base.yaml#L267-L275

systemctl --user start podman.socket
export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock

pack builder create ${IMAGE} --config builder.toml ${PACK_ARGS}

I wonder - how does the buildah build task manage to run in-cluster? Could we use the same trick?

[brianwcook]

Buildah and Podman share libraries, but Podman adds more. Buildah is a lower level tool. It is the more that Podman brings that is the issue. Buildah in Podman / CRI-O works fine; Podman in podman / CRI-O does not. A lot of it has to do with how Podman tries to remap uids and gids.

[ifireball]

Buildah and Podman share libraries, but Podman adds more. Buildah is a lower level tool. It is the more that Podman brings that is the issue. Buildah in Podman / CRI-O works fine; Podman in podman / CRI-O does not. A lot of it has to do with how Podman tries to remap uids and gids.

so IIRC this PR is about getting Buildah on the VM - so could we have it running inside a PODMAN container on the VM instead?