Describe the bug
Unable to delete VolumeSnapshot when the underlying ONTAP snapshot is in "busy" status due to a pv created from that VolumeSnapshot. VolumeSnapshot deletion fails or hangs without clear indication of the dependency issue.
NetApp Support Case: 2010378266 -> history and logs are there
Environment
- Trident version: 25.02 -> to newer
- Container runtime: containerd v2.1.1 and newer
- Kubernetes version: 1.31.x -> and newer
- OS: SLES 16
- Other: ONTAP Version: 9.16 and newer
To Reproduce
Steps to reproduce the behavior:
- Create a VolumeSnapshot from an existing PVC
- Create a new PVC from that VolumeSnapshot (clone operation)
- Attempt to delete the original VolumeSnapshot
- Observe that the VolumeSnapshot cannot be deleted due to the ONTAP snapshot being in busy status.
- It can only be deleted if it is removed from the backend
Expected behavior
Either or :
- Clear error message indicating the VolumeSnapshot cannot be deleted due to dependent PVCs
- Automatic cleanup/finalizer that prevents deletion until dependencies are resolved
- Documentation clearly stating the deletion order requirements
- Kubernetes VolumeSnapshots should be deletable without requiring manual backend intervention — Trident should handle the ONTAP snapshot busy state gracefully
Additional context
Workaround: deleting manually volumeSnapshots from backend or remove finalizers and force delete volumesnapshot from k8s
Suggested improvements:
- Better error messaging when VolumeSnapshot deletion is blocked by dependencies
- Validation webhooks that prevent deletion when dependencies exist
- Enhanced documentation about the deletion order for VolumeSnapshots and their clones
- Trident should handle the ONTAP snapshot busy state gracefully, either by automatically managing dependencies or by implementing proper finalizers that handle cleanup in the correct order
Describe the bug
Unable to delete VolumeSnapshot when the underlying ONTAP snapshot is in "busy" status due to a pv created from that VolumeSnapshot. VolumeSnapshot deletion fails or hangs without clear indication of the dependency issue.
NetApp Support Case: 2010378266 -> history and logs are there
Environment
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Either or :
Additional context
Workaround: deleting manually volumeSnapshots from backend or remove finalizers and force delete volumesnapshot from k8s
Suggested improvements: