NetApp
Issue NDMC: Inconsistent Trident volume naming between YAML-created PVCs and UI-created PVCs with ISO
We are observing inconsistent behavior in ONTAP internal volume/LUN naming when using Trident with a nameTemplate defined in the backend. Our Trident backend (TridentBackendConfig) is configured with:
defaults: nameTemplate: "Openshift-{{.volume.RequestName}}"
✅ Expected Behavior When creating a PVC via YAML (for example, a blank PVC), the ONTAP internal name correctly follows the PVC name. kind: PersistentVolumeClaim metadata: name: sanjeev
→ ONTAP internal name: Openshift-sanjeev
❌ Actual Behavior When creating a volume via OpenShift UI, specifically when uploading an ISO through the Virtualization → DataVolume → Upload workflow: The PVC is created, but the ONTAP internal name is generated with a random/scratch-based pattern such as: Openshift_prime_pvc_<UUID>_<shortID>
This happens even though the final PVC name is correct (rhel-naming-vm-volume, ubuntu-iso, etc.). It looks like CDI (Containerized Data Importer) is provisioning temporary PVCs under the hood, and Trident uses those names internally instead of the requested PVC name.
Steps to Reproduce :
Configure a Trident backend with: defaults: nameTemplate: "Openshift-{{.volume.RequestName}}"
Create a PVC via YAML with blank: {} or normal spec → ONTAP name matches PVC name ✅. Create a PVC via OpenShift UI: Go to Virtualization → DataVolumes → Upload DataVolume. Upload an ISO into a new PVC. Observe the resulting ONTAP internal name → it has tmp_pvc<UUID> prefix ❌.
Environment :
OpenShift: 4.19.x Trident: (25.xx) ONTAP: (9.12.x) Backend: ontap-san with FCP (NetApp ONTAP SAN SVM)
Impact :
Hard to correlate PVCs with ONTAP LUNs when ISO-based DataVolumes are created. Manual disaster recovery workflows become slower because names are inconsistent.
BLANK_PVC_Created :
ISO_PVC_Created:
As you can see over here that my PVC name is windows-jagdish And my internal name is internalName: Openshift_prime_1fb356c8_c8e8_4452_b596_f8b0b502c0d1_31186
There is a mismatch according to the configuration that we had set, our name should have to be like this : nternalName: Openshift_windows-jagdish_....
Hello, @ankushjha-aj. It appears you are correct when you say "CDI (Containerized Data Importer) is provisioning temporary PVCs under the hood". As the CSI provisioner, Trident never sees the volume name that you enter, so I'm unsure how we could fix this.
Hey @clintonk, I wanted to provide an update and some additional findings from my side. The behavior I reported earlier was observed in my DC environment, where my Trident backend was configured with the following template:
defaults: nameTemplate: "Openshift-{{.volume.RequestName}}"
However, after spending time debugging and tracing the provisioning workflow, I found inconsistent behavior across environments. In my DR environment setup, where I use a slightly different naming convention, the internal volume naming works exactly as expected. That said, even though this configuration works correctly, it still doesn’t fully meet my intended manual naming convention requirements — I would prefer the ONTAP internal volume name to directly reflect the PVC name (e.g., Openshift_windows-jagdish), including during CDI-based uploads. If there’s any possibility to address or improve this behavior, I would really appreciate your guidance.
While debugging, I observed that in the DC environment, when uploading ISOs through the OpenShift Virtualization → DataVolume → Upload workflow, CDI (Containerized Data Importer) creates temporary/scratch PVCs internally. This causes Trident to use those temporary PVC names while applying the {{.volume.RequestName}} template, resulting in internal names like:
In contrast, in my DR environment, the backend uses the following configuration:
defaults: nameTemplate: "Openshift-{{.volume.Name}}"
And this setup behaves correctly — internal names follow a consistent and predictable format.
Here are some SS, which may help you to understand the naming convention.
Here, you can see my internal name is : internalName: Openshift_pvc_640b3abe_414c_41ec_a023_80f7ac1b59dc
Here, you can see my internal name is : internalName: Openshift_pvc_96bed963_a009_4225_9993_c6f56fd06427
Why I Believe This Needs Attention is because, From what I’ve understood (please correct me if I’m wrong):
- volume.Name corresponds to the internal PV name automatically generated by OpenShift, such as pvc-640b3abe-414c-41ec-a023-80f7ac1b59dc.
- volume.RequestName corresponds to the PVC name that I define manually, such as baymax-win16-volume.
If my backend uses {{.volume.Name}}, I get names like: Openshift_pvc_640b3abe_414c_41ec_a023_80f7ac1b59dc which works technically fine.
However, my goal is to achieve manual naming consistency — for example, if my PVC name is baymax-win16-volume, I want my ONTAP internal volume name to appear as: Openshift-baymax-win16-volume (in suffix if it adds any random value that is fine) So, if I change my backend to use {{.volume.RequestName}} instead of {{.volume.Name}}, I would expect that result. But instead, the internal volume name becomes something like: Openshift_prime_pvc__... (Which you can see in my earlier messages)
This inconsistency makes it difficult to correlate volumes across environments, especially for manual DR operations and LUN mapping during cutover or validation. For a small setup of around 10–20 VMs, this might still be manageable — even with 30–40 VMs, I could maintain an external inventory to track mappings. However, in our case, we have approximately 400 VMs, and maintaining such an inventory manually for every cutover or recovery operation is not feasible or scalable. I believe you would also agree that this level of manual correlation defeats the purpose of having consistent automation and naming through Trident templates.
@ankushjha-aj agree that the current behaviour of OpenShift with the options provided in Trident for the custom names are not enough to achieve the consistency required. As you have rightly put that the PV names are derived during the creation time and they are not changed when the same PV is bound to a new PVC.
Unfortunately, only .volume.Name and .volume.RequsetName are the only two options available in templates to uniquely name the PVs which are not useful in your case.
