Snapshot deletion with flexclones

[LMedcalf-T-Mobile]

Describe the solution you'd like
When a request is submitted to delete a snapshot that is locked by a flexclone, the request should be denied to be consistent with the experience in ONTAP.

Describe alternatives you've considered
We've spent many hours attempting to make the clone split happen faster or earlier, but the step itself is not needed and is inconsistent with how ONTAP handles the request directly.
Clone splits are still an option and should be available if requested, but not automatically triggered by another request.

Additional context
mirror the response as documented here: https://docs.netapp.com/us-en/ontap/volumes/snapshot-copies-flexclone-files-luns-concept.html#:~:text=You%20cannot%20manually%20delete%20a%20snapshot%20from%20which,locked%20until%20the%20background%20block-sharing%20process%20is%20completed.

[wonderland]

My personal view here: Not sure that would be a good idea as it exposes implementation details of the underlying Ontap system into K8s. From a K8s perspective, each PVC, Clone (PVC with data source) and Snapshot is an independent resource without any further dependencies. This might not be true for the underlying storage system, but that is abstracted away by the CSI driver (such as Trident). If Trident would "deny" a snapshot deletion due to a dependency that doesn't even exist from a K8s perspective, that would be very confusing for the typical K8s user.

Can you share some more details on when the clone split process causes you trouble? Maybe there are other ways to achieve the desired outcome?

[LMedcalf-T-Mobile]

(NetApp cases 2010565244, 2010586430, 2010539505, I'm available via my sales team for discussions.)
As part of it's post-backup cleanup process, a backup application is requesting snapshot deletion on parent volumes prior to deleting the clone. This is forcing a clone split and adding considerable load to the ONTAP cluster as it tries to crunch anywhere from 40-300 clone splits at once.
THAT in turn is delaying response back to the backup application so it is timing out, sometimes triggering a second attempt at the snapshot delete, which triggers another clone split. (We've seen 2 or 3 clone split jobs on a single volume at times)
Increasing the clone split delay to 5 minutes did not appreciably change behavior, and our concern with further increasing it is that the app will wait even longer before failing. (Also, it would likely mean that we'd see clone split storms at the end of that timeout period, instead of immediately.)
The issue is not so much WHEN it does the clone split, as it is WHY it does the clone split at all.
Denying the snapshot delete call with a message that the function is unavailable while a clone exists is a reasonable response and consistent with the way the storage platform works.
Configuring for "split on clone" is an option, but in our use case an unnecessary one as it adds the split delay earlier in the process which would delay the start of backup operations instead of triggering during cleanup as it does now.

Assuming that the client wants to do a clone split (in this case incorrectly) is causing performance issues preventing further implementation of Trident in our environment.