feat(CSI-344): delete filesystems out-of-band if not waiting for object deletion

[sergeyberezansky]

TL;DR

Improved CSI plugin latency on DeleteVolume by moving the deletion of actual filesystem and NFS permissions to asynchronous flow. This behavior is configurable via pluginConfig.waitForObjectDeletion flag

What changed?

• Added retry logic (up to 5 attempts with 1-second intervals) when deleting NFS permissions to handle transient failures such as concurrent deletion of multiple entries at once.
• Added cache invalidation of filesystem object upon getUnderlyingSnapshots
• Improved error message to indicate when NFS permission deletion fails after multiple attempts

How to test?

1. Create a volume with NFS transport
2. Delete the volume and verify that NFS permissions are properly cleaned up

Why make this change?

These changes address latency of DeleteVolume request by moving the deletion into out-of-band thread. The retry logic for NFS permission deletion helps overcome transient API failures that could possibly block filesystem deletion, for example in case of multiple deletions at once that require massive changes to NFS server reconfiguration.

[sergeyberezansky]

• fix(CSI-322): fix SELinux policy missing on UBI container #447
• feat(CSI-316): support encryption with custom settings per filesystem #444
• breaking(CSI-314): remove legacy volume support #435
• feat(CSI-334): allow using multiple mounters in parallel on same server #465
• feat(CSI-344): delete filesystems out-of-band if not waiting for object deletion #477 👈 (View in Graphite)
• dev

This stack of pull requests is managed by Graphite. Learn more about stacking.

[graphite-app]

Graphite Automations

"Request reviewers once CI passes" took an action on this PR • (03/11/25)

1 reviewer was added to this PR based on Sergey Berezansky's automation.