Listener: Add global conn limit opt out.#18876
Conversation
|
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
Signed-off-by: Weston Carlson <wez470@gmail.com>
927965c to
8c82329
Compare
Signed-off-by: Weston Carlson <wez470@gmail.com>
Signed-off-by: Weston Carlson <wez470@gmail.com>
Signed-off-by: Weston Carlson <wez470@gmail.com>
Signed-off-by: Weston Carlson <wez470@gmail.com>
Signed-off-by: Weston Carlson <wez470@gmail.com>
adisuissa
left a comment
There was a problem hiding this comment.
Thanks for working on this.
Left a couple of comments on API and docs.
docs/root/configuration/operations/overload_manager/overload_manager.rst
Outdated
Show resolved
Hide resolved
Signed-off-by: Weston Carlson <wez470@gmail.com>
|
@adisuissa PTAL, thanks. |
adisuissa
left a comment
There was a problem hiding this comment.
I just realized there are 3 things in play after this PR:
- The global connections# limit (runtime flag)
- The per-listener connections# limit (runtime flag)
- The proposed ignore global-connections# limit field (for both the admin and general listeners).
It may be somewhat hard to understand which of these override the others.
Question: would it make sense to have just the global and local limits, where the local limit overrides the global, and if set to 0, it is unlimited?
I guess these can also be fields instead of runtime flags.
|
Thanks for the comments @adisuissa!
This would satisfy the behaviour we want but I believe it's a question more so for maintainers. Making local limits override the global one is a breaking change. Today they can be used in tandem and a listener will be limited if it hits either limit. Further, AFAICT there's no way to set a local limit on the admin listener. So there's no way it could opt out without work to introduce some sort of local limit setting there. |
Signed-off-by: Weston Carlson <wez470@gmail.com>
|
@wez470 would you be able to
Listener connection limit allows overriding global limit down. Having a separate flag to override up makes sense to me. I think we could make it so that if the listener limit is larger than global limit it acts as override up, but it may just make config more complicated. |
I'll look into doing this. For the override up flag, were you thinking this would be a runtime flag? |
|
I've realized that |
|
Given the below diagram: I wonder if we'd want to end up with something more granular than global limits, but provide a grouping mechanism among subsets of listeners. e.g. Implement listener sets as in the middle of the diagram where listener 2 and 3 are limited by some maximum number, while listener 1 is not. This would be a more generalized approach than global limit opt out (solving this use case of opting out the admin, and some particular listeners), and enable cases such as multi-tenant connection limits. I think it would add some additional configuration complexity (e.g. to set up groups), but the behavior seems more predictable / intuitive than overriding possibly occurring in both directions. Thoughts? |
yanavlasov
left a comment
There was a problem hiding this comment.
LGTM, modulo small const correctness nit.
/wait
|
@KBaichoo I like this idea. It is a little more work than I'd hoped to do to solve this issue personally, but I'm open to it if it's agreed that's the directions we should go. |
KBaichoo
left a comment
There was a problem hiding this comment.
@wez470 I'm also happy with the current solution (opt out) as it seems to be heading in the direction where we might eventually want to go and is more intuitive than overriding bidirectionally based on implicit values or implicit comparisons.
docs/root/configuration/operations/overload_manager/overload_manager.rst
Outdated
Show resolved
Hide resolved
Signed-off-by: Weston Carlson <wez470@gmail.com>
Signed-off-by: Weston Carlson <wez470@gmail.com>
|
You might want to merge again since #19007 disabled a flaky QUIC test. |
|
Thanks |
Signed-off-by: Weston Carlson <wez470@gmail.com>
KBaichoo
left a comment
There was a problem hiding this comment.
@adisuissa can you take a look as API Sheppard?
|
@yanavlasov Can you PTAL? |
|
Thanks all for reviewing! |
* main: (77 commits) Fix verify_and_print_latest_release logic (envoyproxy#19111) http2: drain only once when reached max_requests_per_connection (envoyproxy#19078) Overload: Reset H2 server stream only use codec level reset mechanism (envoyproxy#18895) Update QUICHE from c2ddf95dc to 7f2d442e3 (envoyproxy#19095) tools: Fix dependency checker release dates bug (envoyproxy#19109) cve_scan: Use `envoy.dependency.cve_scan` (envoyproxy#19047) tcp: fix overenthusiastic bounds on the new pool (envoyproxy#19036) dep: update Proxy-Wasm C++ host (2021-11-18). (envoyproxy#19074) build(deps): bump frozendict from 2.0.7 to 2.1.0 in /tools/base (envoyproxy#19080) kafka: dependency upgrades (envoyproxy#18995) build(deps): bump charset-normalizer in /tools/dependency (envoyproxy#19105) build(deps): bump slack-sdk in /.github/actions/pr_notifier (envoyproxy#19093) dep: Remove dependency - six (envoyproxy#19085) Remove requested_server_name_ field from StreamInfo (envoyproxy#19102) broken link path fix for items http_filters/grpc_json_transcoder_filter (envoyproxy#19101) quic: turn off GRO (envoyproxy#19088) Listener: Add global conn limit opt out. (envoyproxy#18876) Specify type for matching Subject Alternative Name. (envoyproxy#18628) Fix a broken example in Lua filter docs (envoyproxy#19086) Fix a small typo (envoyproxy#19058) ... Signed-off-by: Michael Puncel <mpuncel@squareup.com>

Commit Message: Add listener global conn limit opt out.
Additional Description: Allows listeners (including the admin) to opt out of the globally set max downstream connections limit. Further info on why this is desired can be read in the linked issue. Individual listeners that have opted out of the global connection limit can still set a local limit using https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/runtime.
Risk Level: small
Testing: function, unit, integration
Docs Changes: Added api docs + mention in overload manager docs
Release Notes:
Fixes #18678