Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support providing per-workload proxy tasks with drain context #899

Closed
bleggett opened this issue Apr 9, 2024 · 3 comments
Closed

Support providing per-workload proxy tasks with drain context #899

bleggett opened this issue Apr 9, 2024 · 3 comments

Comments

@bleggett
Copy link
Contributor

bleggett commented Apr 9, 2024

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:

  • 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.

@daixiang0
Copy link
Member

I do not see the drain-rs crate in the cargo.toml

@bleggett
Copy link
Contributor Author

I do not see the drain-rs crate in the cargo.toml

It's just called drain: https://github.com/istio/ztunnel/blob/master/Cargo.toml#L43

@howardjohn
Copy link
Member

I think this is mostly done and just 1 final task tracked in #1191

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants