workflows: build within emulated container

[synarete]

Use QEMU to build samba-operator within containerized environment; either AMD64 or ARM64 architectures (regardless of local host architecture). Using this method we can ensures that all build tools are properly configured on architectures other than default x86_64, without relaying on specific hardware.

Signed-off-by: Shachar Sharon [email protected]

[phlogistonjohn]

First off, let me apologize for taking so long to look into this. It's really quite cool.

I spent some time messing around a bit and I think we can greatly simplify things. I was able to build and run an arm64 version of the operator container image using the standard Dockerfile and Makefile. I don't think the additional new Dockerfile.build is necessary. Similarly I don't know if the shell script is needed, but it could be useful to adapt it to mainly check for the special dependencies needed to build an arm64 build on a non-arm platform.

I was able to build the container using the command make image-build CONTAINER_BUILD_OPTS="--build-arg=ARCH=arm64 --arch=arm64" . Passing --build-arg=ARCH=arm64 is a hack to work around the Makefile attempting to set this. We can probably improve the Makefile for cross-arch builds.

I "verified" the build using:

podman run --rm -it --entrypoint bash 16b10d8a51de0aec89779607a9fb6a5832bee10578d78856a5dae47288299348
[root@327e42ebd0f1 /]# uname -a
Linux 327e42ebd0f1 6.0.14-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Dec 19 17:45:48 UTC 202
2 aarch64 aarch64 aarch64 GNU/Linux
[root@327e42ebd0f1 /]# microdnf install /usr/bin/file
# .... skipping output ...
[root@327e42ebd0f1 /]# file /manager
/manager: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, Go BuildID=wDkxWtmscaJMu0wHuHeF/mvwDPYmJ8DIO96dDH_T0/HKg4JErou2UbBnVZiVqS/BhnanVhaZqsk5EoLlrck, not stripped

Which is super cool!

I also experimented building a samba-container project image a similar way:

$ make build-server BUILD_OPTS="--build-arg=ARCH=arm64 --arch=arm64"
#  ... skipping output ...
$ podman run --entrypoint bash --rm -it e574947e3c00fefd46a4dcbaa0e503b6d344b40e213fa985507f234a412dd2a9
[root@a094fff2c838 /]# rpm -qa | grep samba
samba-common-4.16.9-0.fc36.noarch
samba-common-libs-4.16.9-0.fc36.aarch64
samba-client-libs-4.16.9-0.fc36.aarch64
samba-libs-4.16.9-0.fc36.aarch64
samba-dc-libs-4.16.9-0.fc36.aarch64
samba-dcerpc-4.16.9-0.fc36.aarch64
python3-samba-dc-4.16.9-0.fc36.aarch64
samba-common-tools-4.16.9-0.fc36.aarch64
samba-4.16.9-0.fc36.aarch64
python3-samba-4.16.9-0.fc36.aarch64
samba-winbind-modules-4.16.9-0.fc36.aarch64
samba-winbind-4.16.9-0.fc36.aarch64
samba-winbind-clients-4.16.9-0.fc36.aarch64
samba-client-4.16.9-0.fc36.aarch64
python3-sambacc-0.3~57.gbc579c9-1.fc36.noarch

I didn't really run the builds "in anger" though. (I'm wishing I had a arm64 SBC right now to fool around with too ;-) )

I think we can start by adapting the workflow you have and just using this emulation technique to build, but not push, the arm image to prevent any possible cross platform regressions. Later, I think we need to investigate https://podman.io/blogs/2021/10/11/multiarch.html which may impact how we build in general - before we start pushing arm64 images to quay (for example).

[synarete]

@phlogistonjohn Fascinating findings! I was able to have same results on my local machine as well (+ more).

1. As far as I remember, I also tried this path with podman, but at the time failed to have those results. It could be due to wrong build args but I suspect that now I using a newer version of podman.

2. I also tried to follow the instructions at https://podman.io/blogs/2021/10/11/multiarch.html but hit some issues so decided to abandon this path. Again, could be related to older podman version.

3. Note that /proc/cpuinfo shows local host machine (unlike in the qemu version). However, not a problem in out use case.

4. Following the above results, I suggest we to reject this PR and I will prepare a new one using podman and existing Makefile (with the appropriate changes).

[phlogistonjohn]

[...SNIP...]

4. Following the above results, I suggest we to reject this PR and I will prepare a new one using podman and existing Makefile (with the appropriate changes).

Fine by me, PR numbers are not a precious resource. :-)

Let me know if you plan on doing the new PR or you'd like me to start, as I now have the needed bits to try it out.

[synarete]

[...SNIP...]
4. Following the above results, I suggest we to reject this PR and I will prepare a new one using podman and existing Makefile (with the appropriate changes).

Fine by me, PR numbers are not a precious resource. :-)

Let me know if you plan on doing the new PR or you'd like me to start, as I now have the needed bits to try it out.

@phlogistonjohn This PR should now be abandoned in favor of #301

[phlogistonjohn]

Closing per previous comment.