Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support running the solr operator on ARM nodes #686

Open
fliphess opened this issue Feb 12, 2024 · 4 comments
Open

Support running the solr operator on ARM nodes #686

fliphess opened this issue Feb 12, 2024 · 4 comments

Comments

@fliphess
Copy link

I'd love to be able to run the solr-operator on ARM architecture.
At the moment this is not possible because the zookeeper operator is unmaintained and not available for ARM.

As our k8s cluster is only running ARM nodes now, we have to keep a few AMD machines just for our SOLR cluster to run the zookeeper operator which is a lot of wasted resources because of that.

@mmoscher
Copy link
Contributor

mmoscher commented Feb 13, 2024

@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.

@fliphess
Copy link
Author

@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
Copy link
Contributor

@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:

image

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 git@github.com: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 🍻

@janhoy
Copy link
Contributor

janhoy commented Feb 13, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants