Cannot persist data between cluster create/destroy/create

[armenr]

The basic gist

I use "throw-away" clusters for local development with k3d.

With other charts like postgres, rabbitmq, etc...I am able to create a PV + PVC outside of the chart, and then pass in the PVC name to the helm chart.

With the local-path provisioner, this allows me to persist data between cluster create/destroy cycles. In other words, it allows me to locally persist data on my development machine, and when I recreate my local cluster from scratch, my data in postgres or rabbitmq is persisted, even when the cluster is destroyed.

I also have similar use-cases in CI/CD pipelines as well.

I LOVE ArangoDB, and have been using it since 2018. I also really appreciate just how great and high-quality the k8s operator is, and how much work has gone into it and its documentation.

I have read through everything I can, I've tried to dive through source-code, and I've gone through GitHub issues as well, but I need help.

I cannot seem to persist the data in a single-node ArangoDeployment no matter what I try.

Based on the example I found here: https://arangodb.github.io/kube-arangodb/docs/how-to/recovery.html#create-pv-and-pvc, and also some GitHub Issues I read through, I have been attempting to get a single-node deployment to work with explicit pv/pvc so that I can persist my Arango data between cluster creation/destruction cycles.

I have included the manifests I am trying to apply as well (a PV, a PVC, and a ArangoDeployment).

Any help or assistance would be greatly, greatly appreciated.

Thank you! 😎

The YAML

---
apiVersion: v1
kind: PersistentVolume
metadata:
  labels:
    arango_deployment: single
    role: single
  name: dbserver-9xztmg4t-vka6ic19qcl1y3ec
spec:
  storageClassName: local-path
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 1Gi
  hostPath:
    path: /var/lib/rancher/k3s/storage/pv-arango-local
    type: DirectoryOrCreate
  persistentVolumeReclaimPolicy: Retain
  volumeMode: Filesystem
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  labels:
    app: arangodb
    arango_deployment: single
    role: single
  name: single-dbserver-9xztmg4t
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: local-path
  volumeMode: Filesystem
  volumeName: dbserver-9xztmg4t-vka6ic19qcl1y3ec
---
apiVersion: database.arangodb.com/v1
kind: ArangoDeployment
metadata:
  name: arango-local
  namespace: data-services
spec:
  mode: Single
  auth:
    jwtSecretName: None
  externalAccess:
    type: None
  single:
    volumeClaimTemplate:
      spec:
        accessModes:
          - ReadWriteOnce
        storageClassName: local-path
        resources:
          requests:
            storage: 1Gi
status:
  members:
    dbservers:
      - id: SNGL-9xztmg4t
        persistentVolumeClaim:
          name: single-dbserver-9xztmg4t
        persistentVolumeClaimName: single-dbserver-9xztmg4t

[ajanikow]

Hello @armenr !

In this scenario, you can change the indexMethod for single servers: https://arangodb.github.io/kube-arangodb/docs/api/ArangoDeployment.V1.html#specsingleindexmethod (please use instructions for the EE Operator; this feature is not hidden behind a license for single servers).

This will ensure that you can predict the member's ID so you can create PVC before (PVC is also not removed after Deployment deletion, so you can recreate deployment).

Best Regards,
Adam.

[armenr]

@ajanikow - Thank you so much for the kind, quick, and helpful reply!

I will test shortly and then post back/close the the issue. Thank you!

[armenr]

@ajanikow

This YAML:

apiVersion: database.arangodb.com/v1
kind: ArangoDeployment
metadata:
  name: arango-singleton
  namespace: data-services
spec:
  mode: Single
  auth:
    jwtSecretName: None
  externalAccess:
    type: None
  single:
    indexMethod: ordered

When describing the ArangoDeployment object in the data-services namespace, I do see this:

❯ kubectl describe ArangoDeployment -n data-services | grep 'Index' -C 3
    Encryption:
  Single:
    Count:         1
    Index Method:  ordered
    Resources:
    Volume Claim Template:
      Metadata:
--
      Encryption:
    Single:
      Count:         1
      Index Method:  ordered
      Resources:
      Volume Claim Template:
        Metadata:

But what I get back is a server named: arango-singleton-sngl-fgffrp9q-6e369b

Is that expected? I was thinking it would just be a sequentially-named member/pod, no?

[ajanikow]

Hello @armenr !

Please use kube-arangodb-enterprise instead of kube-arangodb as your image.

Best Regards,
Adam.

[armenr]

Thanks. Testing again!

[ajanikow]

Hello @armenr !

Did it solve your issue?

Best Regards,
Adam.