Trident controller pod logs repeated errors related to VolumeAttachment objects
- Views:
- 18
- Visibility:
- Public
- Votes:
- 0
- Category:
- trident-openshift
- Specialty:
- snapx
- Last Updated:
- 5/27/2025, 5:58:57 AM
Applies to
- Astra Trident 25.02.1
- OpenShift (OCP)
- ODF Ceph
Issue
- After upgrading Astra Trident to 25.02.1 in OpenShift environment, the csi-attacher container within the Trident controller pod logs repeated errors related to VolumeAttachment objects:
E0321 09:38:33.876403 1 csi_handler.go:190] "VolumeAttachment attached status and actual state do not match. Adding back to VolumeAttachment queue for forced reprocessing" driver="csi.trident.netapp.io" VolumeAttachment="csi-9a140c9f5fa7a1ed81bc172c9e4555e20e242643fcd778088abc92b77063b358" volumeHandle="<volume_handle>" attachedStatus=true found=false
This error repeats for numerous VolumeAttachment objects (e.g., csi-fdce15e60a940e05ba7f490ec5d9c5c7cebc69b511f67569ef5a9af4ab36ae6c, etc.), all with volumeHandle values following the Ceph/ODF naming convention (e.g., 0001-0011-openshift-storage-...), not Trident’s expected format
- Running
kubectl get volumeattachment --all-namespaces
shows VolumeAttachment objects associated with csi.trident.netapp.io, which correctly corresponds to a Trident-managed Persistent Volume (PV) with the driver csi.trident.netapp.io