volumesnapshotcontent-bound-protection finalizer is not removed although volumesnapshot-being-deleted annotation is set

[dploeger]

(this is probably a follow-up to #248)

What happened:

I wanted to delete a namespace, which also triggered the deletion of the volume snapshots in this namespace. However, the volumesnapshotcontent resources were never removed. Only after manually removing the volumesnapshotcontent-bound-protection finalizer, all resources could be removed. Additionally, no events were logged that might lead to an error in the backend.

What you expected to happen:

The volumesnapshots and the respective volumesnapshotcontent resources are deleted successfully. Or, if any error occurs, the resources have events attached to them.

How to reproduce it:

Delete a volumesnapshot.

Anything else we need to know?:

Our environment is based on VMware Tanzu

Environment:

• Driver version: csi.vsphere.vmware.com/91183325 (?)
• Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.5+vmware.wcp.1", GitCommit:"c088f942056efb7cd7b4c8709078812b6343d5fa", GitTreeState:"clean", BuildDate:"2023-09-18T04:30:05Z", GoVersion:"go1.20.7 X:boringcrypto", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v5.0.1
Server Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.11+vmware.1-fips.1", GitCommit:"5ee2bbaec1d784e90139d89e8795921629453218", GitTreeState:"clean", BuildDate:"2024-02-19T20:56:33Z", GoVersion:"go1.21.7 X:boringcrypto", Compiler:"gc", Platform:"linux/amd64"}

• OS (e.g. from /etc/os-release):VMware Photon OS 3.0
• Kernel (e.g. uname -a): Linux int-default-dkgsc-66488c4554x88fdb-9p5sc 4.19.307-6.ph3 #1-photon SMP Sat Apr 6 14:24:47 UTC 2024 x86_64 GNU/Linux

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[akloss-cibo]

This seems to be the case for me as well. Deleting things seems like a fundamental capability; is there something we're misunderstanding about how deleting these resources should be done?

[nixpanic]

Today I tried to reproduce this with Ceph-CSI/RBD on a pre-release of OpenShift 4.17, with the following Kubernetes version:

$ oc version
Client Version: 4.12.6
Kustomize Version: v4.5.7
Server Version: 4.17.0-ec.3
Kubernetes Version: v1.30.3

With the following steps, I was not able to reproduce the problem:

1. create a namespace external-snapshotter-1112
2. create a PVC and VolumeSnapshot in the new namespace
3. verify that the PVC is bound, and the VolumeSnapshot is ready with a VolumeSnapshotContent
4. delete the external-snapshotter-1112 namespace

After deleting the namespace, the VolumeSnapshotContent is removed without much delay.

If these steps are incomplete, please let me know and I'll try again.

In case this problem persists, maybe consider checking with VMware/Tanzu support?

[nixpanic]

/triage needs-information

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten