Change:
using the `PersistentVolume`, Kubernetes clears the `pv-protection` finalizer, and the controller deletes the volume. <ins> {{<note>}} * When you `DELETE` an object, Kubernetes adds the deletion timestamp for that object and then immediately starts to restrict changes to the `.metadata.finalizers` field for the object that is now pending deletion. You can remove existing finalizers (deleting an entry from the `finalizers` list) but you cannot add a new finalizer. You also cannot modify the `deletionTimestamp` for an object once it is set. * After the deletion is requested, you can not resurrect this object. The only way is to delete it and make a new similar object. {{</note>}} </ins> ## Owner references, labels, and finalizers {#owners-labels-finalizers} Like {{<glossary_tooltip text="labels" term_id="label">}},

Discussion:
states that finalizers can be used to block deletion indefinitely. However, there is no explicit statement on updates to deletionTimestamp. It would make sense to prevent updates other from zero to some value, but if that's the case, it should also be mentioned here. This might look like a detail, but it is an important one when designing controller deletion protocols.
/retitle Clarify updates to during object removal /sig api-machinery /language en
Hi there is a very good regarding finalizers that mention deletionTimestamp. PTAL. If I'm understanding right this blog might help.
Hi I get how the deletion protocol works in Kubernetes. I also get why that's the case. What I ask is to extend the documentation with the guarantee that, once a deletion timestamp has been set to a nonzero value, it will never get another value thereafter. The issue is that there are guides to use finalization for indefinite deferral of the actual delete. But, there is no mechanism to actually abort the delete. Thus, if someone decides to manually delete a resource that cannot be deleted that way, the only fix for this is either to have a protection finalizer and completely ignore deletion timestamp or to replace the resource with an equivalent copy. Furthermore, I ask for a specific documentation, because the interaction with ownership is non-trivial and one should be assured that whatever is implemented will stay that way in future versions.
When you an object, Kubernetes makes that object almost read-only. If the object has no finalizers then the read-only object can disappear right away. Otherwise, the “read only” object is changed to record the timestamp that it was frozen. It's almost read-only because: the field gets set you can remove, but not add or change, finalizers As far as I know, admission control checks still apply. For example, if there's a ValidatingAdmissionWebhook that restricts removal of a particular finalizer, the restrictions still happen even for an object that's being deleted. Let's clearly document that objects being finalised are read-only with the exceptions I've mentioned. Then the immutability of goes without saying. If we want to we can explain the implication: you cannot resurrect an object that is has already had deletion requested; you can only delete it and then make a new similar object.
Thanks, that clarification would be great.

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, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/triage accepted Hi !contribution is welcome regarding this issue. As it has been long time without any comments , i''d like to ask if you want to work on this?
If you are not working on it ,I'll be happy to update the text as this information/note is quite helpful in understanding the concept with clarity.
/remove-lifecycle stale
Hi I'm currently not working on this.
Thanks for clarifying . /assign
Raised PR: for the same.PTAL is this what you expected ? please let me know
yes, thanks; left a comment in the PR