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

MeshTimeout incorrect default value for http.streamIdleTimeout #12648

Closed
lobkovilya opened this issue Jan 23, 2025 · 2 comments
Closed

MeshTimeout incorrect default value for http.streamIdleTimeout #12648

lobkovilya opened this issue Jan 23, 2025 · 2 comments
Labels
kind/bug A bug triage/pending This issue will be looked at on the next triage meeting

Comments

@lobkovilya
Copy link
Contributor

What happened?

In docs it says 30m https://kuma.io/docs/2.9.x/policies/meshtimeout/#defaults. In practice it's 5s because of this line

StreamIdleTimeout: &kube_meta.Duration{Duration: policies_defaults.DefaultGatewayStreamIdleTimeout},

should be:

StreamIdleTimeout: &kube_meta.Duration{Duration: policies_defaults.DefaultStreamIdleTimeout},
@lobkovilya lobkovilya added kind/bug A bug triage/pending This issue will be looked at on the next triage meeting labels Jan 23, 2025
@lobkovilya
Copy link
Contributor Author

same for http.maxConnectionTimeout 😞

MaxConnectionDuration: &kube_meta.Duration{Duration: policies_defaults.DefaultConnectTimeout},

lobkovilya added a commit that referenced this issue Jan 27, 2025
## Motivation

When we test `BuildRules` we pass MeshTimeout policies as input and
check `outbound.ResourceRules` Go struct.

When we test MeshTimeout plugin we pass `outbound.ResourceRules` Go
struct as input and check envoy configs.

We need an easy way to pass MeshTimeout policies and check envoy
configs. It's sort of an integration test that involves 2 packages. The
easiest way to do that is to add another universal e2e test with golden
files. This way we have running Kuma CP and we basically test it as a
black box.

I managed to find 2 bugs using these tests:
* #12648
* #12649

## Implementation information

We check DPP `config` (marshalled Snapshot in Kuma CP) instead of the
actual Envoy config dump for a few reasons:
* no need to add logic that waits while config is propagated on DPP
* less setup-specific values we have to reduct to have stable golden
file (only IP addresses)
* we can use `kuma.io/effect: shadow` and quickly review the `diff`
policies introduces

---------

Signed-off-by: Ilya Lobkov <[email protected]>
@lobkovilya
Copy link
Contributor Author

closing in favor of #12667

@lobkovilya lobkovilya closed this as not planned Won't fix, can't repro, duplicate, stale Jan 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug A bug triage/pending This issue will be looked at on the next triage meeting
Projects
None yet
Development

No branches or pull requests

1 participant