distribution/Dockerfile-ubi: add containerfile for bootc-foundry

[croissanne]

distribution/Dockerfile-ubi: add containerfile for bootc-foundry

This container will be used to build the bootc derived containers.

Using buildah in a rootless container requires:
- using vfs as a storage driver as the nested container won't have
access to the fuse device;
- letting the nested container use the host container's user namespace
mapping as the host container won't be able to create a new mapping;
- using the chroot isolation mechanism to let the nested container use
the host container's network and pid namespaces (amongst other things).

[achilleas-k]

Neat! LGTM.

Some questions but nothing that needs changing.
Except that commit thing, but I wont block.

[croissanne]

@ondrejbudai you know stuff about containers. I'm pretty sure that on the openshift cluster we won't have much access to special capabilities or the fuse device and things like that. As a result I've resorted to using vfs here.

This makes the bootc containers very large of course but I think if we'll delete each container after pushing we should be fine? My main worry is if this can have an effect on the actual artifact that's being pushed? Like the container should be the same regardless of storage backend and isolation mechanism used, right?

[lzap]

We how test RHEL builds twice, I think you can drop them from the matrix. So this still can run in parallel with CentOS and Fedora.

[croissanne]

We how test RHEL builds twice, I think you can drop them from the matrix. So this still can run in parallel with CentOS and Fedora.

removed the 3 builds from the matrix that are now happening in the container (cs9, cs10, and rhel9). But when we write the build matrix declaratively in a separate file, i'll maybe introduce filtering for the entrypoint.py script so we can parallelise it again / build parts of the matrix.

[lzap]

I really do not like 27 minutes long test, could we change it a bit? I get the idea that we want to stay as close as possible to RHOS, in that case let's make a 180 deg turn and build everything this way, but let's allow for parallel jobs. The entrypoint could be configurable so in gitlab matrix we can specify which nodes will build what. This way, we can at least speed it up here, what you think?

This makes the bootc containers very large of course but I think if we'll delete each container after pushing we should be fine? My main worry is if this can have an effect on the actual artifact that's being pushed? Like the container should be the same regardless of storage backend and isolation mechanism used, right?

Yes, the result in the end is basically a tarball with JSON metadata. It is up to the container engine to perform more sophisticated storage operations like deduplication or things like that.

[achilleas-k]

Like the container should be the same regardless of storage backend and isolation mechanism used, right?

I think if it's not, then something went very wrong.

[croissanne]

around 11 minutes for the slower centos ones now (ig it depends on how fast the registry is as well).

[lzap]

Great thanks!