Problem definition

While deploying our Bitbucket instance to Kubernetes, we identified an issue with the sharedHome section of the values.yaml file under the Bitbucket Helm chart. Specifically, the persistentVolume section does not contain a storageClassName field, unlike the persistentVolumeClaim, which automatically sets the storageClassName.

As a result, when deploying Bitbucket, the PersistentVolumeClaim (shared-home) remains in the Pending state until its corresponding PersistentVolume is manually assigned to the same storageClassName as the PersistentVolumeClaim. This situation causes an inconsistency between the persistentVolume and persistentVolumeClaim.

Suggested Solution

Can we add an additional line to the Helm chart, right under persistentVolume, to assign a storageClassName, just as we are doing for persistentVolumeClaim? This would ensure consistency between both resources and avoid the need for manual intervention.

Current config:

sharedHome:
  persistentVolume:
    create: true
    nfs:
      server: "<NFS Server>"
      path: "<NFS Path>"
      mountOptions: []
  persistentVolumeClaim:
    create: true
    storageClassName: <StorageClass name>

Proposed Configuration:

sharedHome:
  persistentVolume:
    create: true
    storageClassName: <StorageClass name>  # Add this line
    nfs:
      server: "<NFS Server>"
      path: "<NFS Path>"
      mountOptions: []
  persistentVolumeClaim:
    create: true
    storageClassName: <StorageClass name>