Backport of Add ServiceResolver RequestTimeout for route timeouts to make TerminatingGateway upstream timeouts configurable into release/1.15.x #16520
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport
This PR is auto-generated from #16495 to be assessed for backporting due to the inclusion of the label backport/1.15.
WARNING automatic cherry-pick of commits failed. Commits will require human attention.
The below text is copied from the body of the original PR.
Description
I'm not entirely sure about this approach because it's unclear to me where we generally useEdit: Adding a RequestTimeout parameter for ServiceResolvers to handle the timeout. That said, this change allows for overriding Envoy's default timeout for establishing connections to upstream clusters in a route configuration.ConnectTimeout
forServiceResolver
s and whether or not this is conflating two timeout values that shouldn't be conflated. If so, I can add another timeout value that makes this configurable.I tested it manually with a custom go binary run on the mesh with a
TerminatingGateway
andServiceResolver
that extends the timeout to 30 seconds so that a server that takes 20 seconds to respond doesn't timeout. I'll be adding some sort of integration test, but wanted to open this to get eyes on the approach first.Note that two changes are necessary for this to work with terminating gateways, the first is to allow the local proxy that a service uses to route traffic through the mesh to configure the timeout for its routes via
makeUpstreamRouteForDiscoveryChain
, the second is to have theTerminatingGateway
itself configure its routing timeouts viamakeNamedDefaultRouteWithLB
.Testing & Reproduction steps
The files I used to manually validate are here. I compiled
main.go
astimeout-check
, copied it to the root of the consul directory and locally compiled consul. I then booted up Consul, ran thetimeout-check.sh
script and issued acurl
tolocalhost:9877
to kick off a request through the service mesh to the external sleeping service. Without this change I see:➜ ~ curl localhost:9877 upstream request timeout%
With it I see:
➜ ~ curl localhost:9877 finished%
PR Checklist
Overview of commits