wmgroot

> How would that function with the `out-of-service` taint? The pods need to be aware that they need to be removed before the `out-of-service` taint is added in this case....

Isn't that already how it works without any extra logic that references the pods' terminationGracePeriodSeconds? When a Node or NodeClaim is deleted, it starts a drain on the node, which...

We have the same issue and we're currently running a patch that outright disables Karpenter removing nodes with non-evictable and non-disruptible pods from the disruption candidate filtering process. This patch...

To be specific, would you be looking to implement a solution for allowing disruption to occur on nodes with non-evictable or non-disruptible pods? I believe my `terminationGracePeriod` PR will already...

Having also thought about this issue more, I think what you were envisioning would be an effective "disruption delay" where: 1. A node becomes considered for disruption. 2. The node...

With my understanding of @jmdeal 's proposal, you'd be able to set the `candidateTTL` for each NodeClaim to `0s`, which would let the standard drain and `terminationGracePeriod` logic start immediately....

What you're describing would meet my use case. I don't think it should be incorporated into the current PR since it's close to finalized and I'd like to avoid any...

My PR is one piece needed to solve the problem, but not a complete solution on its own. I've been pretty busy with work fires the past week, but I'm...

As a heads up for anyone watching this the `terminationGracePeriod` PR is being updated to also handle disruption for non-evictable and do-not-disrupt pods: https://github.com/kubernetes-sigs/karpenter/pull/916

Tests added.