Finalizer for ThirdPartyResourceData

[brendandburns]

Mentioned elsewhere, but not fully covered in an issue.

Need to add a finalizer to wipe out etcd data on object deletion.

@kubernetes/sig-api-machinery

[deads2k]

Mentioned elsewhere, but not fully covered in an issue.

Need to add a finalizer to wipe out etcd data on object deletion.

I agree. Related to kubernetes/enhancements#95

[caesarxuchao]

Do you mean delete all the thirdpartyResourceData when the thirdpartyResource is deleted?

[deads2k]

Do you mean delete all the thirdpartyResourceData when the thirdpartyResource is deleted?

Yeah. Otherwise recreation of the same TPR does whacky stuff.

[caesarxuchao]

Looks like it could use the synchronous garbage collection: https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/synchronous-garbage-collection.md

[liggitt]

no need for the delete API call to hang while it's trying to clean up the related third party, an async finalizer seems like it would be better

[deads2k]

no need for the delete API call to hang while it's trying to clean up the related third party, an async finalizer seems like it would be better

From what I gather, synchronous garbage collection doesn't block the delete call. The delete call completes without deleting the resource, instead it marks a finalizer and at some later point a controller cleans up the dependants and deletes the head.

[liggitt]

does that require setting ownerRef on every thirdpartyresourcedata object?

[deads2k]

does that require setting ownerRef on every thirdpartyresourcedata object?

Now that bit makes me very unhappy. None may remain, and ownerRef may allow some to escape.

[brendandburns]

I thought about this some more, I think the simplest solution is to mark the TPR as 'deleting' which has the effect of blocking all new writes to the TPR, but doesn't actually delete it. Then a GC controller picks up the TPRs that are deleting and works to delete all of the resources owned by that TPR.

Once the TPR is actually empty, then it is deleted by the GC controller.

Thoughts?

[deads2k]

Then a GC controller picks up the TPRs that are deleting and works to delete all of the resources owned by that TPR.

Once the TPR is actually empty, then it is deleted by the GC controller.

Thoughts?

Because the GC controller can be influenced by the end user (user who can modify a Foo, can remove the ownerRef), I think that unsuitable. I want the stronger control of an unconditional finalizer.

@adohe the finalizer issue I mentioned.

[adohe-zz]

@deads2k Thanks :)

[enisoc]

This is fixed for CustomResource, the new version of TPR. Users should migrate to CustomResource, as there are no plans to add a finalizer for TPR which is now deprecated.