multiarch support (arm64 specifically)

[scoof]

Describe the feature you'd like to have.
We would like to be able to run snapscheduler on arm64. It seems like the Makefile already supports multiarch, so this should be a matter of using the docker-buildx target to build.
I've been unable to figure out how/where images are built/published, so I can't make this change as a PR.

What is the value to the end user? (why is it a priority?)
arm64 is generally cheaper, so a good option for running k8s workloads

How will we know we have a good solution? (acceptance criteria)
When snapscheduler can run on arm64 nodes

[scoof]

@JohnStrunk anything I can do to help this along? Can you tell me how/where you build images, so I can PR that?

[JohnStrunk]

Sorry... this slipped through the cracks.

The images are build via GH actions here:

snapscheduler/.github/workflows/tests.yml

Lines 84 to 107 in bbc0bb8

	build:
	name: Build
	runs-on: ubuntu-20.04
	steps:
	- name: Checkout source
	uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab # v3.5.2
	- name: Install Go
	uses: actions/setup-go@4d34df0c2316fe8122ab82dc22947d607c0c91f9 # v4.0.0
	with:
	go-version: ${{ env.GO_VERSION }}
	- name: Build operator container
	run: make docker-build IMAGE=${IMAGE}
	- name: Export container image
	run: docker save -o /tmp/image.tar ${IMAGE}
	- name: Save container as artifact
	uses: actions/upload-artifact@0b7f8abb1508181956e8e162db84b466c27e18ce # v3.1.2
	with:
	name: container
	path: /tmp/image.tar

The built artifacts are then used in the e2e test matrix, and finally pushed to quay here:

snapscheduler/.github/workflows/tests.yml

Lines 246 to 290 in bbc0bb8

	push:
	name: Push container to registry
	needs: [e2e-success]
	if: >
	(github.event_name == 'push' || github.event_name == 'workflow_dispatch') &&
	(github.ref == 'refs/heads/master' || startsWith(github.ref, 'refs/tags/v'))
	runs-on: ubuntu-latest
	steps:
	- name: Load container artifact
	uses: actions/download-artifact@9bc31d5ccc31df68ecc42ccf4149144866c47d8a # v3.0.2
	with:
	name: container
	path: /tmp
	- name: Import container image
	run: |
	docker load -i /tmp/image.tar
	docker inspect ${IMAGE}
	- name: Login to registry
	# If the registry server is specified in the image name, we use that.
	# If the server isn't in the image name, default to docker.io
	run: |
	[[ "${IMAGE}" =~ ^([^/]+)/[^/]+/[^/]+ ]] && REGISTRY="${BASH_REMATCH[1]}" || REGISTRY="docker.io"
	echo "Attempting docker login to: ${REGISTRY}"
	echo "${{ secrets.REGISTRY_PASSWORD }}" | docker login -u "${{ secrets.REGISTRY_USERNAME }}" --password-stdin ${REGISTRY}
	- name: Push to registry (latest)
	if: >
	(github.event_name == 'push' || github.event_name == 'workflow_dispatch') &&
	github.ref == 'refs/heads/master'
	run: |
	docker push "${IMAGE}"
	- name: Push to registry (version tag)
	if: >
	(github.event_name == 'push' || github.event_name == 'workflow_dispatch') &&
	startsWith(github.ref, 'refs/tags/v')
	run: |
	[[ "${{ github.ref }}" =~ ^refs/tags/v([0-9]+\..*) ]] || exit 0
	TAG="${BASH_REMATCH[1]}"
	echo "Pushing to $TAG"
	docker tag "${IMAGE}" "${IMAGE}:${TAG}"
	docker push "${IMAGE}:${TAG}"

Some thoughts...

• Adjusting the build to be multi-arch should be pretty straightforward.
• I'm not sure what to do about the testing. I guess for now, we just won't test the non-x64 images
• Since the images get exported and re-imported, I'm not sure how difficult it will be to get that part working

[bmgante]

Really interested on this... What are the plans to turn ARM image available?

[scoof]

Really interested on this... What are the plans to turn ARM image available?

I don't really have the time to do this at the moment.

[bmgante]

When you have some time to do that pls just let me know