I have no opposition to this plan, though personally I tend to like the bigger "pet tool container" pattern where I yum -y install buildah in there.

It feels like we should at least document that in upstream buildah's README.md. Now if one is pushing to a remote registry it's AIUI not even required to mount the host's /var/lib/containers - one can use an host-mounted scratch directory. I may take a crack at that too.

I have no opposition to this plan, though personally I tend to like the bigger "pet tool container" pattern where I yum -y install buildah in there.

As in build the container with a released version of buildah as opposed to building a buildah binary from a release and placing it in a stripped image?

As in build the container with a released version of buildah as opposed to building a buildah binary from a release and placing it in a stripped image?

I think he's just pointing out that he would just install the buildah rpm into his "tools" container that's basically a catchall for a bunch of things. i.e. do we need a buildah container when users can just install the rpm into a pet container. I think the answer is yes, because we need to provide users with something specific to use that we know will work. Thoughts?

The more generic the container the more complex the mounts and (likely) wider the permissions become. I'm not against doing a tools container though it's just something to keep in mind.

I'm going to close this issue as my understanding from the buildah folks is that they will provide an image and we will be able to utilize that. If for some reason this is a misunderstanding I'll reopen this.