Support running the solr operator on ARM nodes

[fliphess]

Support running the solr operator on ARM nodes

[janhoy]

Zk operator is not a hard req. I recommend disabling it and instead run a zk ensemble with bitnami’s zk helm chart which also has more up to date zk images.

[fliphess]

@mmoscher We run on arm64 graviton machines on AWS and the default zookeeper-operator image shipped with it, does not support running on graviton for us. It does on m1/m2/m3 because of rosetta (I think) but on a "just arm64" cloud instance we cannot get it to run.

You are right that this is more of an issue on the zookeeper-operator but as that ships as a hard dependency of the solr-operator and as there are no alternatives available other than running some amd64 machines, I do think this is related to the solr operator itself as a project too.

Did you manage to get the zookeeper-operator build for arm64 working? Because I'd love to use your branch as I don't expect any upstream fixes to be merged any time soon as the zookeeper-operator maintenance seem to have stalled a bit.

[mmoscher]

@fliphess yes ya totally right. We're running the zookeeper-operator as well.

Just double-checked our local deployment. Colima spawns - when running with k3s - an aarch64 instance as default (which should be the same as arm64). However the mac virtualization does some magic as well. Zookeeper itself claims to be running in amd64:

Didn't know this yet, learned something new today 😆 . Need to double-check this tomorrow. This, however, explains why we do not have any issues running our deployment locally on m1/m2 macs.

Nevertheless, 2 years ago - when prepping for the macs to arrive - I managed to get up and running our local deployment on a GCP Tau T2A instance.
Thus, I was able to run the zookeeper-operator on ARM. So you should be able to use my branch/fork for it.
Feel free to contribute back any changes/fixers you need to make on the way. Maybe it will be merged upstream any time soon. Keep in mind that need to build both, the operator and the zookeeper image itself. Furthermore, keep in mind that you need to have buildx with qmeu in-place or you have to run your builds directly in the graviton machines.

My wrapper script to perform the build was the following:

#!/usr/bin/env bash
set -e

pushd "/tmp"

echo "[INFO] Building zookeeper operator ..."
git clone [email protected]:mmoscher/zookeeper-operator.git && pushd "zookeeper-operator"

TAG=0.2.14
REPO=your-repo/zookeeper

docker buildx build \
		--push \
		--build-arg VERSION=$TAG \
		--platform=linux/amd64,linux/arm64 \
		-t ${REPO}-operator:$TAG \
		.

docker buildx build \
		--push \
		--build-arg VERSION=$TAG \
		--platform=linux/amd64,linux/arm64 \
		-t ${REPO}:$TAG \
		./docker

popd
rm -rf zookeeper-operator
echo "[INFO] zookeeper operator done ..."

Hf 🍻

[mmoscher]

@fliphess what issue do face in particular?
We've currently 5 developers on Mac M1 or M2 (arm64) using colima for local development, and they are able to use the solr-operator smoothly. For setup we use Zookeeper as dependency only and do not, for some time past, deploy the operator separately.

Using the Zookeepers CRDs got use covered:

# Install all Solr CRDs as well as the dependency CRDS (ZookeeperCluster) for the given version of the Solr Operator
kubectl create -f "https://solr.apache.org/operator/downloads/crds/<solr operator version>/all-with-dependencies.yaml"

cf. https://apache.github.io/solr-operator/docs/running-the-operator#the-zookeepercluster-crd

However, if you prefer to using the operator, you can try to get the following PR merged. I started to implement arm64 support 2 years ago, but didn't had (and not have) the time to get it finished yet:
pravega/zookeeper-operator#504

One way or another, this (your) issue is IMHO not related to the solr-operator.