Describe the bug
Observed:
- Volumes remain in deleting state
- orphaned=true
- GCNV volume still exists
- PV removed
- no deletionTimestamp
- backend healthy
- publish/unpublish operations still succeed
Logs:
Backend update resulted in an orphaned volume.
workflow=cr=reconcile
Additional observation:
Tenant repeatedly sees orphaned-volume events when creating subordinate volumes from master volumes.
Environment
Provide accurate information about the environment to help us reproduce the issue.
- Trident version: 26.02.1
- Trident installation flags used: trident-installer-26.02.1/trident-installer/deploy/bundle.yaml
- Container runtime: CRI-O
- Kubernetes version: v1.33.12
- Kubernetes orchestrator: OpenShift 4.20.27
- Kubernetes enabled feature gates:
- OS: RHEL 9.8
- NetApp backend types: GCNV
- Other: Flex Unified storage pools
To Reproduce
creating subordinate volumes will cause orphaned errors on the master volume
Expected behavior
If a PVC was deleted in OpenShift/kubernetes, the PVC should also be deleted in GCNV
Additional context
Add any other context about the problem here.
Describe the bug
Observed:
Logs:
Backend update resulted in an orphaned volume.
workflow=cr=reconcile
Additional observation:
Tenant repeatedly sees orphaned-volume events when creating subordinate volumes from master volumes.
Environment
Provide accurate information about the environment to help us reproduce the issue.
To Reproduce
creating subordinate volumes will cause orphaned errors on the master volume
Expected behavior
If a PVC was deleted in OpenShift/kubernetes, the PVC should also be deleted in GCNV
Additional context
Add any other context about the problem here.