pr for collaborating on disruption probe issue

[ryanmcnamara]

No description provided.

[ryanmcnamara]

internal comment:

cc @dhenkel92 @K8Y
link to our planning doc: https://docs.google.com/document/d/1ZYxoaJHyO1y47ZdivjsF5Ahem8iDfU8bb-LjdFII67M/edit?tab=t.0#heading=h.73pjmgwdo15h

• we have heard that there is likely to be pushback from sig-node from @tim and others (TODO what others kaitlyn?) due to the complexity of it and the fact that sig node is under strain. We decided we wanted to pursue it anyway as it probably would work the best for us so it's good to at least document that we pursued this route.
• TODO Tim mentioned there was a KEP at one point that was shot down that had to do with disruption priority, this doesn't meet our use case but is worth finding if we're able
  • ask tim on the issue we file
• we should expect pushback on blocking disruption. People will likely have a knee jerk reaction that we are trying to treat pods as "special"
• do we want to suggest/mention disruption++ similar to readiness++? or leave it out?
  • A: refer to controller solution and talk about it briefly (done)
• I accidentally started this issue on the mainline kubernetes repo 🤦 draft kubernetes/kubernetes#129592

here the recommend against what we are doing (making an issue instead of a kep or as a precursor to a kep), I think it's fine

[rifelpet]

It might be worth mentioning the Node Lifecycle WG proposal and the two associated KEPs, given that they intend to focus on pod disruption:

https://github.com/kubernetes/community/pull/8396/files#diff-71b686071e3803f2cb5c56afea196bcd2ba94ce2485b0cef5ad73d65fa9b6a41R11

[dhenkel92]

It might be worth mentioning the Node Lifecycle WG proposal and the two associated KEPs, given that they intend to focus on pod disruption:

That's a great idea. I've added a small sentence in the bottom and we'll see if we can meet someone from the new WG in London.