Big +1 on implementing this and making it a generic principle across resources. Definition and logic for graceful vs non-graceful termination for each resource belongs in the server, not in client pieces like "kubecfg stop."

Thinking about the CLI perspective, I could imagine 3 operations:

• Raw, brute-force REST operation, not necessarily graceful nor clean: delete
• Graceful shutdown: stop
• Clean but ~immediate shutdown: cancel

Proposed approach: Add a "stop" or "shutdown" field to each object's spec, and then support a custom verb, e.g. /op/stop or /op/shutdown, to set the field.

I'd also like to add a suspend field to each object to make it stop making changes.

Assuming we move forward with #3613, I would like to expose a pattern where I can effectively stop a Namespace, mark all of its content for deletion by some background controller, and then ultimately purge the Namespace resource. Reading through this thread and others, it's not clear we have consensus on the right pattern for this across resources. Is there a recommended pattern to follow that I can look to prototype? I feel like I need a separate resource (NamespaceTermination) that I can post to kick off the proper workflow as I tend to agree that a DELETE should remain a true delete.

The XxxTermination resource could be protected via a separate policy so it's not confused with traditional PUT. Acceptance of the XxxTermination would toggle a Status field on the resource. A controller would see the resource marked for termination and perform all required cleanup. Upon completion, a client with proper Policy rights would send the DELETE to the Namespace resource. A delete would be accepted iff the resource was in a Terminated status, and the final resource removal would complete. In the interim, clients could do normal Get operations on the internal resources to track the purge to completion. This seems like the general flow I would look to prototype this week.

@derekwaynecarr My proposed approach was here: #1535 (comment). We may need to bikeshed about the names/paths, though. You could think of the "custom verb" as a synthetic control resource, such as XxxTermination.

I'm happy to have "stop" and "delete" be distinct. We can provide the ability to do both in a single operation in kubectl.

We need existence dependencies for cascading deletion in the server. Deployments generate ReplicaSets which generate Pods. Doing cleanup in the client will be fragile and unfriendly to non-kubectl clients.

cc @nikhiljindal @janetkuo @ironcladlou @ncdc

/sub

Closing in favor of #19054, which is being implemented for 1.3.

We have the garbage collector in place now but is there an umbrela issue or separate issues for making it work for all of the resources that need graceful deletion?

We have the garbage collector in place now but is there an umbrela issue or separate issues for making it work for all of the resources that need graceful deletion?

Maybe #26120?