MySQL Bugs: #109797: Mysql operator doesn't have arm64 image

Bug #109797	Mysql operator doesn't have arm64 image
Submitted:	26 Jan 2023 21:19	Modified:	27 Jan 2023 13:18
Reporter:	Ales Verbic (OCA)	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Operator	Severity:	S3 (Non-critical)
Version:	8.0	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
Mysql operator image is based on oraclelinux which supports (linux/amd64, linux/arm64/v8) it would be nice if https://hub.docker.com/r/mysql/mysql-operator/tags would be published for arm64 arch too.

How to repeat:
It doesn't work on ARM arch.

Suggested fix:
Could you update the docker builds CI/CD to build ARM images?

Hello Ales Verbic,

Thank you for the report and reasonable request.

regards,
Umesh

Is it possible to know some time expectations for this change to be implemented?

Bug #110075 marked as duplicate of this one

Hello,

I would like to inform you that it is impossible to bootstrap the MySQL cluster with the MySQL operator on the ARM64 Kubernetes cluster.

First of all, if you are running the arm64 cluster you need to update images on CRDS and operator manifest files. That is doable. However, once you are starting the cluster - you still get issues with architecture and containers spanned with wrong architecture images. Sad.

The operator's code should be smart enough to select correct images according to architecture or images for different architectures should be uploaded over the same tag. The current setup is:
8.1.0-aarch64 linux/arm64
8.1.0         linux/amd64

It should be:
8.1.0 linux/arm64
8.1.0 linux/amd64

Hello Gediminas Jancys, it looks we now have the mysql tags with the desired state you mentioned for deploying in arm64, that said it would be great to have mysql-operator in my arm64 cluster.

I think made a mistake, the tags with the desired state is mysql not mysql-operator :-(

Ok, it was not impossible but very inconvenient, I was able to run mysql-operator in my arm64 kubernetes cluster replacing the following value in helm install: 
image:
 tag: 8.1.0-2.1.0-aarch64

Then I got into that situation it was mentioned about pulling the image tag without the "-aarch64" so I used https://github.com/phenixblue/imageswap-webhook/ in order to replace the tags:
[EXACT]container-registry.oracle.com/mysql/community-operator:8.1.0-2.1.0::container-registry.oracle.com/mysql/community-operator:8.1.0-2.1.0-aarch64
    [EXACT]container-registry.oracle.com/mysql/community-server:8.1.0::container-registry.oracle.com/mysql/community-server:8.1.0-aarch64

it's ugly but it works :-)

Hi there, I am also interested in this feature.
I've been playing around with it on EKS
It works if I manually change the config for the cluster's stateful set to add -aarch64 to each version found. Then after the cluster is up also changing the mysql-routers version.
I see issues though with backups and something else using the wrong image :(

I personally don't want to install something like imageswap-webhook. Just another thing I have to worry about when upgrade k8s.

Hey Steven, yeah I forgot to mention one more tag, these are the correct values:
[EXACT]container-registry.oracle.com/mysql/community-operator:8.1.0-2.1.0::container-registry.oracle.com/mysql/community-operator:8.1.0-2.1.0-aarch64
[EXACT]container-registry.oracle.com/mysql/community-server:8.1.0::container-registry.oracle.com/mysql/community-server:8.1.0-aarch64
[EXACT]container-registry.oracle.com/mysql/community-router:8.1.0::container-registry.oracle.com/mysql/community-router:8.1.0-aarch64

But I faced some issues regarding the cluster auto generated users and it's passwords when messing with the databases and I had to delete everything each time I touched any setting in the manifests, and apart from that I found that the mysql-operator was an overkill for my purposes, so I ended up using mysql standalone and https://github.com/Angatar/mysql-s3-backup for backups, which works very well.

Thanks for the insights sounds like we have similar needs, i also want to do s3 backups. i might play around with this more and try to get it working.

On the other hand i might bite the bullet and use intel chips (20% more expensive in my case)

My plan is to use this soln for 3 yrs, so i want some assurances and like what this operator has to offer.

Is there any resolution to this issue, rather than workarounds? I'm using arm64 platform for cluster and get exec format error. I tried the arm64 Helm charts from https://canozokur.github.io/mysql-operator/ and still have the exec error on pods created.

Another work around is pushing up the `community-operator:1.2.3-aarch64` image named as the amd image, e.g. `community-operator:1.2.3` to your own private or public repository.

This can be done overwriting the environment variables found here - https://github.com/mysql/mysql-operator/blob/trunk/helm/mysql-operator/values.yaml#L14-L15 (`MYSQL_OPERATOR_DEFAULT_REPOSITORY`).

Although I do strongly agree that the Oracle supplied images should be multi architecture and under a single tag.

I wanna bump this issue. It's just ridiculous that in 2025 there's no support for ARM64.

When can we expect it guys? What's missing on actually doing the work to support it?