You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What we really need beyond that PR with inpod is more granular drains than ztunnel is equipped with currently, at a minimum I can imagine the following:
Drain(reason: workload gone) -> workload gone, don't wait for connections to "unstick" - just drop.
Drain(reason: proxy terminating) -> workloads are not gone, but whole proxy is going - start refusing conns and give workloads a grace period.
This is relatively easily accomplished with regular tokio::sync channels, we should probably just replace our use of https://github.com/linkerd/drain-rs (which is a very light wrapper around those) with use of the tokio sync primitives directly.
ALSO - as part of this we should have draintests for EVERY handler.
inbound
outbound
inbound_passthrough
socks5
dns
that test that they are all guaranteed to drain down to 0 tasks when signaled.
The text was updated successfully, but these errors were encountered:
Prompted by #898
What we really need beyond that PR with inpod is more granular drains than
ztunnel
is equipped with currently, at a minimum I can imagine the following:This is relatively easily accomplished with regular
tokio::sync
channels, we should probably just replace our use of https://github.com/linkerd/drain-rs (which is a very light wrapper around those) with use of the tokio sync primitives directly.ALSO - as part of this we should have draintests for EVERY handler.
inbound
outbound
inbound_passthrough
socks5
dns
that test that they are all guaranteed to drain down to 0 tasks when signaled.
The text was updated successfully, but these errors were encountered: