kube-arangodb creates invalid ArangoMember when using cri-o runtime >= 1.28.0

[interphase404]

cri-o in this issue: https://github.com/cri-o/cri-o/pull/7149 changed its way of imageID generation and it was released in 1.28.0 version

1.27.x

- containerID: cri-o://0176720042c54860c1318c9b5f8aa309ddf800c50c098b4dd197c530d062644f
  image: docker.io/arangodb/kube-arangodb:1.2.35
  imageID: docker.io/arangodb/kube-arangodb@sha256:04b9d9c13fc6fe44ba487c97a4b156776d1f3d168161b2c18cfce51f0704963e

1.28.x

- containerID: cri-o://94154294b1448742e3b85cf764208768b0cf49a81f6d3791655d21e4d9bb91cc
  image: docker.io/arangodb/kube-arangodb:1.2.35
  imageID: a516987956f3280347d09c4c663fc00e2380a8f85e62c9bda75afb903395f554

As far as i can tell, kube-arangodb creates "image" value in ArangoMember by using imageID. It has worked perfectly until 1.28.0 release of cri-o. Now it simply is a docker image id and not a valid image name for pod spec

[ajanikow]

Hello!

We will take a look into issue, for now please change: https://github.com/arangodb/kube-arangodb/blob/master/docs/api/ArangoDeployment.V1.md#specimagediscoverymode to direct to workaround your issue.

Best, Adam.

[raphael10-collab]

@ajanikow @interphase404 Can you please explain me what exactly do I have to put in arango-deployment.yaml instead of image: "arangodb/arangodb:3.11.6" ? :

kind: "ArangoDeployment"
metadata:
  name: "arango-cluster"
spec:
  mode: Cluster
  agents:
    volumeClaimTemplate:
      spec:
        storageClassName: local-storage-arango
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 240Gi
        volumeMode: Filesystem
  dbservers:
    volumeClaimTemplate:
      spec:
        storageClassName: local-storage-arango
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 300Gi
        volumeMode: Filesystem
  image: "arangodb/arangodb:3.11.6"

These are my configuration files :

root@k8s-eu-1-control-plane-node-1:~# ls -lah ArangoDBConfig/
total 40K
drwxr-xr-x  2 root root 4.0K Dec  7 12:35 .
drwx------ 22 root root 4.0K Dec  7 09:52 ..
-rw-r--r--  1 root root  676 Dec  7 12:35 arango-deployment.yaml
-rw-r--r--  1 root root  261 Dec  6 16:48 arango-local-storage-class.yaml
-rw-r--r--  1 root root  486 Dec  7 09:51 arango-pv-agent-worker-1.yaml
-rw-r--r--  1 root root  486 Dec  7 09:59 arango-pv-agent-worker-2.yaml
-rw-r--r--  1 root root  486 Dec  7 09:52 arango-pv-agent-worker-3.yaml
-rw-r--r--  1 root root  517 Dec  7 11:42 arango-pv-db-server-control-plane-node-1.yaml
-rw-r--r--  1 root root  517 Dec  7 11:42 arango-pv-db-server-control-plane-node-2.yaml
-rw-r--r--  1 root root  517 Dec  7 09:51 arango-pv-db-server-control-plane-node-3.yaml

Do I have to specify the ArangoDB Docker Image also in arango-pv-db-server-control-plane-node- 1/2/3.yaml files, in arango-pv-agent-worker-1/2/3.yaml files and in arango-local-storage-class.yaml file, or is it enough to specify it in arango-deployment.yaml file ?

[clayroach]

@ajanikow We are also seeing a similar issue with OCI on with kubernetes 1.28 and later. Cross posting the issue https://github.com/arangodb/arangodb/issues/20984

We have implemented the spec.imageDiscoveryMode: direct setting which works for the server container in the pod, but not for the uuid and other init containers. Is there another setting for these?

[ajanikow]

Hello!

Fixed in: https://github.com/arangodb/kube-arangodb/pull/1602

Add --image.discovery.status=false to the Operator Args

Best Regards, Adam.