Describe the bug
When Trident identifies the iSCSI initiators of the nodes, it keeps them in the case they are defined in.
If there are uppercase characters in the IQN, for the first PV for a node, it adds the IQN into the igroup, which lands in it with only lowercase characters (ONTAP adjusts the case, since according to ONTAP, initiator names are case treated independent)
On the second PV, Trident finds the existing igroup, and checks the initiators inside, does find a match (due to the case variance), and tries to add the same initiator again, failing with:
Initiator group \"nmsvr444-8821f106-4166-4c61-ae96-fe23d6a08700\" already contains initiator \"iqn.2026-01.com.netstal:nmsvr444.7shehjs error adding IQN iqn.2026-01.com.netstal:nmsvr444.7shEhjs
Environment
Provide accurate information about the environment to help us reproduce the issue.
- Trident version: 26.02.0
- Trident installation flags used: -n trident
- Container runtime:
- Kubernetes version: v1.34.5+rke2r1
- Kubernetes orchestrator:
- Kubernetes enabled feature gates:
- OS:
- NetApp backend types: ontap-san-economy
- Other:
To Reproduce
Steps to reproduce the behavior:
- Give all nodes in the k8s cluster capitalized letters in the last section of the iSCSI IQN.
- Deploy a pod with two SAN PVs based on iSCSI.
Expected behavior
The check for the initiator should not fail to find the initiator name in the igroup, and should not try to add it again.
i.e. it needs to compare the initiator names in a case independent manner.
It should just map the igroup to the new LUN and continue.
Additional context
ONTAP 9 automatically handles iSCSI initiator names by making them all lowercase.
Even of the node's IQN has uppercase, the LUNs mapped to the node can still be accessed, despite the discreancy, showing that to ONTAP the IQN letter case is inconsequential.
Describe the bug
When Trident identifies the iSCSI initiators of the nodes, it keeps them in the case they are defined in.
If there are uppercase characters in the IQN, for the first PV for a node, it adds the IQN into the igroup, which lands in it with only lowercase characters (ONTAP adjusts the case, since according to ONTAP, initiator names are case treated independent)
On the second PV, Trident finds the existing igroup, and checks the initiators inside, does find a match (due to the case variance), and tries to add the same initiator again, failing with:
Initiator group \"nmsvr444-8821f106-4166-4c61-ae96-fe23d6a08700\" already contains initiator \"iqn.2026-01.com.netstal:nmsvr444.7shehjs error adding IQN iqn.2026-01.com.netstal:nmsvr444.7shEhjsEnvironment
Provide accurate information about the environment to help us reproduce the issue.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The check for the initiator should not fail to find the initiator name in the igroup, and should not try to add it again.
i.e. it needs to compare the initiator names in a case independent manner.
It should just map the igroup to the new LUN and continue.
Additional context
ONTAP 9 automatically handles iSCSI initiator names by making them all lowercase.
Even of the node's IQN has uppercase, the LUNs mapped to the node can still be accessed, despite the discreancy, showing that to ONTAP the IQN letter case is inconsequential.