Setting to override default request timeout

[owenhaynes]

Description:
The default timeout looks to be 10seconds we would like to easily be able to change this globally to 30 seconds. It maybe possible to do this with envoy config patching but this seems overly complicated for a simple change.

[zirain]

there's a lot of timeout in envoy, which one?

[owenhaynes]

we currently set the rule in the httproute

timeouts:
            request: "30s" 

But this is for the full request if I understand. Getting a lot of up stream timeout errors with out this being set

So ideally it would be the response timeout we would like to alter globally as we have some services which can take over 10seconds

So I assume it a global route timeout that is required

[guydc]

Hi @owenhaynes. The timeout that you're referring to in the Gateway API HTTP Route is implemented in EG as Envoy's route timeout: https://www.envoyproxy.io/docs/envoy/latest/faq/configuration/timeouts#route-timeouts. I'm not familiar with an equivalent global Envoy setting.

One thing that can be done here to improve UX is to additionally support this timeout value in EG's ClientTrafficPolicy. Then, you can attach a policy to Gateway, which will make this timeout apply to all routes attached to that gateway.

However, since this creates overlap with existing Gateway-API config, perhaps the best approach is to raise this requirement in Gateway-API.

[owenhaynes]

Yeah I don' think envoy has a global setting for this as a question got asked in the https://groups.google.com/g/envoy-users/c/Bbp3SNLIw8Y

I like the concept of doing this at a ClientTrafficPolicy but this is not great when merge gateways are used as at a platform level we have no control. So maybe the EnvoyProxy resource is a better place. I mean we could add a Kyverno mutation to fix this but that's asking for trouble 😄.

I do like the idea of it being added to the Gateway-API but that is slow moving

[guydc]

EnvoyPatchPolicy is also an option that you can consider here. It supports GatewayClass attachment for the MergeGateways scenario that you describe: https://gateway.envoyproxy.io/v1.0.1/tasks/extensibility/envoy-patch-policy/.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

[galihputera]

I got this issue when trying to perform long-running gRPC server stream (>15s). Try to use patch policy but still unlucky

[arkodg]

looks like this was asked in slack recently as well https://envoyproxy.slack.com/archives/C03E6NHLESV/p1717439123191249
I'd be a +1 to add requestTimeouts to BackendTrafficPolicy so it can be applied globally at the Gateway level

[arkodg]

@galihputera if you are looking at setting request timeouts at the route level, these examples https://gateway.envoyproxy.io/v1.0.1/tasks/traffic/http-timeouts/ should help

[galihputera]

Thanks, @arkodg but I'm asking about the timeout by using grpcroute resource https://gateway.envoyproxy.io/v1.0.1/tasks/traffic/grpc-routing/ seems there is no configuration there yet. We want to enable the grpc-web feature

[arkodg]

I'm proposing adding the requestTimeout field to BackendTrafficPolicy as well
https://gateway.envoyproxy.io/v1.0.1/api/extension_types/#httptimeout, so that

1. it can be applied to the Gateway and set for multiple routes
2. works for GRPCRoute, currently there is no way to set this timeout for it, raised a issue upstream Support Request Timeouts for GRPCRoute kubernetes-sigs/gateway-api#3139
   A workaround here is to use HTTPRoute and add a h2 or h2c value to the applicationProtocol field within the Service backendRef

wdyt @envoyproxy/gateway-maintainers

[shawnh2]

+1 for adding requestTimeout in BTP.

Just one small question: if we apply requestTimeout for Gateway and timeouts.requests for the HTTPRoute at the same time, does the former overwrites latter? or the other way around?

[arkodg]

ah good point, httpRoute.spec.timeouts.request has highest priority and will override the rest

[guydc]

+1 for adding requestTimeout in BTP.

[sanposhiho]

Picking it up.

/assign

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

[sanposhiho]

(No worries, it's not slipped from my list. It's just that my OSS capacity is overwhelmed on k/k side at the moment...)

[arkodg]

np @sanposhiho, we have about a month for the v1.2.0 release