nodeGetInfo does not populate services list with FCP, cannot provision volumes

[CHouse-Insight]

Describe the bug
On a fresh install of OpenShift 4.21.8 on Cisco UCS blades with Fibre Channel HBAs, we successfully boot-from-san and can configure the cluster. multipathd is running by default. lsscsi is not present, and find_multipaths is set to no in /etc/multipath.conf.

However, with a fresh install of NetApp Trident 26.2.0 from the OpenShift software catalog, the hosts never register "FCP" as an available service.

oc get tridentnode -n trident -o custom-columns=NAME:.metadata.name,SERVICES:.hostInfo.services
NAME                                     SERVICES
node1   [NFS iSCSI nvme]
node2   [NFS iSCSI nvme]
node3   [NFS iSCSI nvme]

This results in errors during PV creation "no available backends for storage class".

time="2026-04-09T19:57:16Z" level=debug msg=">>>> CreateVolume" Method=CreateVolume Type=CSI_Controller logLayer=csi_frontend name=pvc-8c943666-9b38-4dc2-9488-a31c0f7e593d requestID=35931975-5b2d-4325-8490-4eac8af8e69d requestSource=CSI workflow="volume=create"
time="2026-04-09T19:57:16Z" level=debug msg="Volume capabilities (1): [block:{}  access_mode:{mode:MULTI_NODE_MULTI_WRITER}]" logLayer=csi_frontend requestID=35931975-5b2d-4325-8490-4eac8af8e69d requestSource=CSI workflow="volume=create"
time="2026-04-09T19:57:16Z" level=debug msg="About to list backends: map[08275607-5117-4e65-a14f-07e36a043967:0xc0012cafa0 8dd7d277-f2e3-4116-8b27-062ca45716c5:0xc001e434a0]" logLayer=core requestID=35931975-5b2d-4325-8490-4eac8af8e69d requestSource=CSI workflow="volume=create"
time="2026-04-09T19:57:16Z" level=debug msg="Found cached PVC by UID." logLayer=csi_frontend name=prime-bad11db7-4746-47ec-931b-44f9392d2f59 namespace=openshift-virtualization-os-images requestID=35931975-5b2d-4325-8490-4eac8af8e69d requestSource=CSI uid=8c943666-9b38-4dc2-9488-a31c0f7e593d workflow="volume=create"
time="2026-04-09T19:57:16Z" level=debug msg="Found PVC for requested volume pvc-8c943666-9b38-4dc2-9488-a31c0f7e593d." UID=8c943666-9b38-4dc2-9488-a31c0f7e593d logLayer=csi_frontend name=prime-bad11db7-4746-47ec-931b-44f9392d2f59 namespace=openshift-virtualization-os-images requestID=35931975-5b2d-4325-8490-4eac8af8e69d requestSource=CSI size="{{32212254720 0} {<nil>} 32212254720 DecimalSI}" storageClass=sc-ptdnaclus1-ptdnaesx02p-aggr1-15tssd-14d2w workflow="volume=create"
time="2026-04-09T19:57:16Z" level=debug msg="Found cached storage class by name." logLayer=csi_frontend name=sc-ptdnaclus1-ptdnaesx02p-aggr1-15tssd-14d2w requestID=35931975-5b2d-4325-8490-4eac8af8e69d requestSource=CSI workflow="volume=create"
time="2026-04-09T19:57:16Z" level=debug msg="Found storage class for requested volume pvc-8c943666-9b38-4dc2-9488-a31c0f7e593d." logLayer=csi_frontend name=sc-ptdnaclus1-ptdnaesx02p-aggr1-15tssd-14d2w requestID=35931975-5b2d-4325-8490-4eac8af8e69d requestSource=CSI workflow="volume=create"
time="2026-04-09T19:57:16Z" level=debug msg="Orchestrator#getProtocol" accessMode=ReadWriteMany logLayer=core protocol= requestID=35931975-5b2d-4325-8490-4eac8af8e69d requestSource=CSI volumeMode=Block workflow="volume=create"
time="2026-04-09T19:57:16Z" level=debug msg="Orchestrator#getProtocol" err="<nil>" logLayer=core requestID=35931975-5b2d-4325-8490-4eac8af8e69d requestSource=CSI resultProtocol= workflow="volume=create"
time="2026-04-09T19:57:16Z" level=info msg="no backend pools support the requisite protocol" logLayer=core requestID=35931975-5b2d-4325-8490-4eac8af8e69d requestSource=CSI workflow="volume=create"
time="2026-04-09T19:57:16Z" level=info msg="no backend pools support any requisite topologies" logLayer=core requestID=35931975-5b2d-4325-8490-4eac8af8e69d requestSource=CSI workflow="volume=create"
time="2026-04-09T19:57:16Z" level=debug msg="nasType request is not present" logLayer=core requestID=35931975-5b2d-4325-8490-4eac8af8e69d requestSource=CSI workflow="volume=create"
time="2026-04-09T19:57:16Z" level=info msg="no backend pools found for given NASType" logLayer=core requestID=35931975-5b2d-4325-8490-4eac8af8e69d requestSource=CSI workflow="volume=create"
time="2026-04-09T19:57:16Z" level=debug msg="Finally got 0 storage pools" logLayer=core requestID=35931975-5b2d-4325-8490-4eac8af8e69d requestSource=CSI workflow="volume=create"
time="2026-04-09T19:57:16Z" level=debug msg="<<<< CreateVolume" Method=CreateVolume Type=CSI_Controller logLayer=csi_frontend name=pvc-8c943666-9b38-4dc2-9488-a31c0f7e593d requestID=35931975-5b2d-4325-8490-4eac8af8e69d requestSource=CSI workflow="volume=create"
time="2026-04-09T19:57:16Z" level=error msg="GRPC error: rpc error: code = Unknown desc = no available backends for storage class sc-ptdnaclus1-ptdnaesx02p-aggr1-15tssd-14d2w" logLayer=csi_frontend requestID=35931975-5b2d-4325-8490-4eac8af8e69d requestSource=CSI

The TridentBackendConfig is configured successfully and we have successful connection to the NetApp.

storageDriverName: ontap-san
sanType: fcp

Our workaround is to patch the node via a CronJob every few minutes to ensure that "FCP" is in the list and now PVs can be successfully created:

oc patch tridentnode <node> -n trident --type=merge \
  -p '{"hostInfo":{"services":["NFS","iSCSI","nvme","FCP"]}}'

In frontend/csi/node_server.go line 855, it seems there is no method to ever append the services with "FCP", which is what is required for provisioning to succeed.

Should there be something added like this?

// Check if FCP is active by verifying fc_host entries exist
if len(hostWWPNMap) > 0 {
    services = append(services, "FCP")
}

Environment
Provide accurate information about the environment to help us reproduce the issue.

• Trident version: 26.2.0 from the OpenShift software catalog
• Trident installation flags used: Installed via OpenShift software catalog web console
• Container runtime: [e.g. Docker 19.03.1-CE]
• Kubernetes version: [e.g. 1.15.1]
• Kubernetes orchestrator: OpenShift 4.21.8
• Kubernetes enabled feature gates: [e.g. CSINodeInfo]
• OS: [e.g. RHEL 7.6, Ubuntu 16.04]
• NetApp backend types: NetApp 9.13.1P8 on AFF-C250
• Other:

To Reproduce
Steps to reproduce the behavior:

Expected behavior
A clear and concise description of what you expected to happen.

Additional context
Add any other context about the problem here.

[wonderland]

From my experience, hostInfo.services is never populated with FCP and that is not required for proper operation (though it differs from all other protocols, so I agree it might be a good idea to make this consistent).

However, hostWWPNMap should be populated in the TridentNode CR. If not, then discovery wasn't successful. It should look something like this:

apiVersion: v1
items:
- apiVersion: trident.netapp.io/v1
  deleted: false
  hostInfo:
    os:
      distro: rhcos
      version: "4.18"
    services:
    - NFS
    - nvme
  hostWWPNMap:
    "0x100070b7e428889c":
    - "0x201e00defb356c01"
    - "0x201e00defb726501"
    "0x100070b7e42888a5":
    - "0x201e8c604ff4fa01"
    - "0x201e00defb726901"
  ips:
  - 10.192.87.1
  - 139.23.18.4
  - 172.16.192.2
  kind: TridentNode

If you don't have the WWPNMap, make sure that zoning is setup correctly and restart the daemonset to trigger re-discovery oc rollout restart ds trident-node-linux -n trident