Suggestion: Use volume UUID instead of `internalName` to link Kubernetes PVs with ONTAP FlexVols

[ecthelion77]

Description
Currently, Trident uses the internalName attribute to establish the link between a Kubernetes PersistentVolume (PV) and the corresponding ONTAP volume. However, this approach presents a significant limitation: while it is possible to rename a volume on the NetApp array, the internalName stored in the Kubernetes PV is immutable.

This creates a mismatch between the actual volume name on the storage backend and the reference stored in Kubernetes, potentially leading to confusion, operational complexity, or even data management issues.

Proposed Improvement
It would be more robust and future-proof to use the volume's UUID (which is immutable and unique) as the primary identifier for linking the PV to the ONTAP volume. This would ensure consistency even if the volume name is changed on the NetApp side.

Benefits

• Avoids inconsistencies between Kubernetes and ONTAP
• Supports renaming volumes on the storage backend without breaking the PV linkage
• Improves traceability and operational flexibility

Environment

• Trident version: 25.02.1
• Kubernetes version: 1.32
• ONTAP version: 9.16.1P4
• Backend config

apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
  creationTimestamp: "2025-06-17T14:56:24Z"
  finalizers:
  - trident.netapp.io
  generation: 2
  labels:
    argocd.argoproj.io/instance: trident-operator
  name: mirror-all-snapshots
  namespace: trident
spec:
  autoExportCIDRs:
  - xxx.xxx.xxx.xxx/xx
  autoExportPolicy: true
  backendName: mirror-all-snapshots
  credentials:
    name: default
  dataLIF: xxx.xxx.xxx.xxx
  defaults:
    nameTemplate: '{{ .labels.cluster }}_{{ .volume.Namespace }}_{{ .volume.RequestName  }}'
    snapshotPolicy: default
  deletionPolicy: delete
  labels:
    policy: mirror-all-snapshots
  managementLIF: xxx.xxx.xxx.xxx
  nfsMountOptions: nfsvers=4
  replicationPolicy: DPDefault
  replicationSchedule: 5min
  storageDriverName: ontap-nas
  svm: SVM_TEST
  version: 1

Additional Context
Let me know if more technical details or logs are needed to illustrate the issue.