Problem with external NFS data when volume data alfready exist

[shazada]

So the use-case is:

• Customer has huge amount of data stored in an NFS
• They don't want to use the PVC created by Alfresco and want to use that volume to mount the drive

So i'm not sure if what we're doing is wrong --> but it's how we've done it in the past years.
At this point when you deploy REPO it triggers the following helper:
https://github.com/Alfresco/alfresco-helm-charts/blob/main/charts/alfresco-common/templates/_helpers-persistence.tpl#L5
This creates a
- name: data

If we disable persistance it still creates the data volume with emptydir 20GI.
Our override_values.yaml looks like this

    extraVolumes:
      - name: data
        nfs:
          path: /data/nfs
          server: xx.xx.x.xx

So it fails to create another data volume, because the previous created bij the helper-class already exist.
To counter this, I've to change the default chart and put and if else around this include:
f03a7a5#diff-becdf0661f6bb1923c084bf71ae8ae8dd78285bd61c4046e839c9f91ca65c44fL194

[alxgomz]

Hi @shazada ,
The approach is to import your existing NFS export as a kubernetes volume within the appropriate storageClass and create a pvc for it in the right namespace before deploying.
Once done, you should be able to point the deployment to the volume using:

repository:
  persistence:
    enabled: true
    existingClaim: myNFSexport

More (hopefully useful) details can be found here: https://github.com/Alfresco/acs-deployment/blob/master/docs/helm/storage.md

[shazada]

@alxgomz thanks! I'll try that.

And how does this work with the service account then:
f03a7a5#diff-becdf0661f6bb1923c084bf71ae8ae8dd78285bd61c4046e839c9f91ca65c44fL192

If I add the NFS without suppliying this serviceAccount whith has NFS capabilities the POD can't connect to NFS.

[alxgomz]

Which CSI driver are you using? Usually we use the EFS CSI drivers which do not requires anything specific (though we use it with dynamic provisioning)

[alxgomz]

Oh I took a second look and I think you might be using the in-old tree kubernetes storage driver (which options such as serverand path).
I remember testing it but that was loooong ago back in the 1.0.x version of the chart. Back then I don't remember any requirement for a service account but of course things may have changed with kubernetes upgrades. Though I dind't find any reference of that in the kubernetes examples.
Having said that. We do not support direct PV usage in deployments and instead require to have a PVC on top of it.
If using this approach you still see the need for. a serviceAccount please let us know what exact API persmission that account needs so we can understand if/where we miss something.