Nick Tran

Sorry for the late response on this, must've passed through my notifications. As a whole I'd rather not have drift detection without deprovisioning built directly into the feature, as the...

> If supporting this mark-only approach, it'll be much more useful as a label (which allows use of a watch to observe newly marked nodes) than as an annotation. @sftim,...

Yes, we're also thinking that it may not make much sense to allow deprovisioning for the budget for different reasons. I have two questions: 1. (I do realize this isn't...

Got it, that makes sense. Since I haven't heard other similar requests, I'm unsure of how likely it is for us to implement this in the near future. If you're...

@wmgroot Can you share how often you're hitting this? From my understanding the race is super small window, so I'm curious exactly how often this is hitting. Are you seeing...

Adding a TLDR on this thread for those who are coming back to this more recently. When you need to ensure different tenants don't schedule onto the same node, you...

While you could just do `kubectl delete node`, it sounds like you want your own custom way to mark nodes for Karpenter to eventually deprovision them. We discussed doing this...

> Long term, I was sorta expecting there are always going to be gaps (is karpenter going to be able to drift on userdata changes for example?). Yeah we should...

I updated the title to be more general based off our discussion. This could look like users adding an annotation/label/taint for Karpenter to discover and then implement it as [another...

@garvinp-stripe or @sidewinder12s, let me know if you want to help implement this. I can help guide through this, and it should be fairly straightforward.