From accce111b996acd78b0978c08da42612e45db52c Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Thu, 4 May 2023 15:20:55 -0400 Subject: [PATCH 01/27] GEP-1742: Timeouts API proposal --- geps/gep-1742.md | 81 +++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 80 insertions(+), 1 deletion(-) diff --git a/geps/gep-1742.md b/geps/gep-1742.md index b2b2b5b641..5e488de5ac 100644 --- a/geps/gep-1742.md +++ b/geps/gep-1742.md @@ -301,8 +301,87 @@ Could not find any HTTP specific timeouts. PRs welcomed. 😊 ## API -TBD. +From the above analysis, it appears that most implementations are capable of supporting +the configuration of simple downstream request timeouts on HTTPRoute rules. This is a +relatively small addition (one new field) that would benefit many users. + +Because request timeouts are very much related to retry attempts, we also propose +addressing issue: [#1731](https://github.com/kubernetes-sigs/gateway-api/issues/1731) +by adding another field for retry conifguration in an HTTPRoute rule. This would also +benefit many users and seems to be implementable by many (most?) Gateway implementations. + +### GO + +```go +type HTTPRouteRule struct { + // Timeout for HTTP requests, disabled by default. + Timeout *time.Duration `json:"timeout,omitempty"` + // Retry policy for HTTP requests. + Retries *HTTPRetry `json:"retries,omitempty"` + // ... +} + +type HTTPRetry struct { + // Number of retries to be allowed for a given request. + Attempts int32 `json:"attempts,omitempty"` + // Timeout per attempt for a given request, including the initial call and any retries. + // Default is the value of the HTTPRouteRule request Timeout. + PerTryTimeout *time.Duration `json:"per_try_timeout,omitempty"` + // Specifies the conditions under which retry takes place. + // One or more conditions can be specified using a ‘,’ delimited list. + RetryOn string `json:"retry_on,omitempty"` + // Flag to specify whether the retries should retry to other localities. + RetryRemoteLocalities *bool `json:"retry_remote_localities,omitempty"` +} +``` + +### YAML + +```yaml +apiVersion: gateway.networking.k8s.io/v1beta1 +kind: HTTPRoute +metadata: + name: timeout-example +spec: + ... + rules: + - backendRefs: + - name: some-service + port: 8080 + timeout: 10s + retries: + attempts: 3 + perTryTimeout: 2s + retryOn: 503 +``` + +### Timeout values + +Timeout and PerTryTimeout values are formatted as 1h/1m/1s/1ms and MUST BE >= 1ms. + +### Retry attempts + +By default, the number of retry attempts is implementation dependent. An implementation MAY +provide external mechanisims for controlling the default retry behavior. + +When a request Timeout in the HTTPRouteRule or PerTryTimeout value is configured, the actual +number of retries attempted may be reduced depending on the specified request Timeout and +PerTryTimeout values. + +An implementation MUST ensure that the number of retries never exceeds the Attempts value, +if specified. + +The interval between retries is implementation dependent but SHOULD be a minimum of 25ms. + +### RetryOn Conditions + +The value of an individual RetryOn condition can be either an HTTP status codes (e.g., 503) +or some other identifier known to the implementation. + +An implementation MUST support any HTTP status code value for a RetryOn condition. +The default conditions that will trigger retries, if no RetryOn conditions are specified, +is implementation dependent. ## Alternatives From 0525880edd17902314e7e6f0abf27a8ab46b6d57 Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Fri, 5 May 2023 11:41:34 -0400 Subject: [PATCH 02/27] address comments --- geps/gep-1742.md | 26 +++++++++++++++++++------- 1 file changed, 19 insertions(+), 7 deletions(-) diff --git a/geps/gep-1742.md b/geps/gep-1742.md index 5e488de5ac..3c169f8188 100644 --- a/geps/gep-1742.md +++ b/geps/gep-1742.md @@ -301,6 +301,12 @@ Could not find any HTTP specific timeouts. PRs welcomed. 😊 ## API +The above diagrams show that there are many different kinds of configurable timeouts +supported by Gateway implementations: connect, idle, request, upstream, downstream. +Although there may be opportunity for the specification of a common API for more of +them in the future, this GEP will focus on the L7 timeouts in HTTPRoutes that are +most valuable to clients. + From the above analysis, it appears that most implementations are capable of supporting the configuration of simple downstream request timeouts on HTTPRoute rules. This is a relatively small addition (one new field) that would benefit many users. @@ -318,7 +324,7 @@ type HTTPRouteRule struct { Timeout *time.Duration `json:"timeout,omitempty"` // Retry policy for HTTP requests. Retries *HTTPRetry `json:"retries,omitempty"` - // ... + // ... } type HTTPRetry struct { @@ -326,12 +332,11 @@ type HTTPRetry struct { Attempts int32 `json:"attempts,omitempty"` // Timeout per attempt for a given request, including the initial call and any retries. // Default is the value of the HTTPRouteRule request Timeout. - PerTryTimeout *time.Duration `json:"per_try_timeout,omitempty"` - // Specifies the conditions under which retry takes place. - // One or more conditions can be specified using a ‘,’ delimited list. - RetryOn string `json:"retry_on,omitempty"` + PerTryTimeout *time.Duration `json:"perTryTimeout,omitempty"` + // Specifies one or more conditions under which retry takes place. + RetryOn []string `json:"retryOn,omitempty"` // Flag to specify whether the retries should retry to other localities. - RetryRemoteLocalities *bool `json:"retry_remote_localities,omitempty"` + RetryRemoteLocalities *bool `json:"retryRemoteLocalities,omitempty"` } ``` @@ -352,7 +357,7 @@ spec: retries: attempts: 3 perTryTimeout: 2s - retryOn: 503 + retryOn: [ "503" ] ``` ### Timeout values @@ -383,6 +388,13 @@ An implementation MUST support any HTTP status code value for a RetryOn conditio The default conditions that will trigger retries, if no RetryOn conditions are specified, is implementation dependent. +### RetryRemoteLocalities + +When an implementation supports prioritizing endpoints based on their locations, this field +can be used to control whether or not retry attempts should only select endpoints with the +same priority (RetryRemoteLocalities=false) or any healthy endpoint, regardless of location +(RetryRemoteLocalities=true). + ## Alternatives (List other design alternatives and why we did not go in that From 7696daae95514bb53433e3d05f2babf7fb227279 Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Mon, 15 May 2023 16:26:44 -0400 Subject: [PATCH 03/27] remove retries proposal --- geps/gep-1742.md | 111 ++++++++++++++++++++++++----------------------- 1 file changed, 56 insertions(+), 55 deletions(-) diff --git a/geps/gep-1742.md b/geps/gep-1742.md index 3c169f8188..89e661e69e 100644 --- a/geps/gep-1742.md +++ b/geps/gep-1742.md @@ -307,36 +307,61 @@ Although there may be opportunity for the specification of a common API for more them in the future, this GEP will focus on the L7 timeouts in HTTPRoutes that are most valuable to clients. -From the above analysis, it appears that most implementations are capable of supporting -the configuration of simple downstream request timeouts on HTTPRoute rules. This is a -relatively small addition (one new field) that would benefit many users. +From the above analysis, it appears that most (all?) implementations are capable of +supporting the configuration of simple client downstream request timeouts on HTTPRoute +rules. This is a relatively small addition that would benefit many users. -Because request timeouts are very much related to retry attempts, we also propose -addressing issue: [#1731](https://github.com/kubernetes-sigs/gateway-api/issues/1731) -by adding another field for retry conifguration in an HTTPRoute rule. This would also -benefit many users and seems to be implementable by many (most?) Gateway implementations. +A client HTTP request to a gateway may result in more than one call to the destination +backend service, for example, if automatic retries are supported. Some implementations +support configuring a timeout for the individual backend requests, seperate from the +overall client request timeout. Adding None-Core support for this would also benefit +many users. ### GO ```go type HTTPRouteRule struct { - // Timeout for HTTP requests, disabled by default. - Timeout *time.Duration `json:"timeout,omitempty"` - // Retry policy for HTTP requests. - Retries *HTTPRetry `json:"retries,omitempty"` + // Timeouts defines the timeouts that can be configured for an HTTP request. + // + // Support: Core + // + // +optional + // + Timeouts *HTTPRouteTimeouts `json:"timeouts,omitempty"` + // ... } -type HTTPRetry struct { - // Number of retries to be allowed for a given request. - Attempts int32 `json:"attempts,omitempty"` - // Timeout per attempt for a given request, including the initial call and any retries. - // Default is the value of the HTTPRouteRule request Timeout. - PerTryTimeout *time.Duration `json:"perTryTimeout,omitempty"` - // Specifies one or more conditions under which retry takes place. - RetryOn []string `json:"retryOn,omitempty"` - // Flag to specify whether the retries should retry to other localities. - RetryRemoteLocalities *bool `json:"retryRemoteLocalities,omitempty"` +// HTTPRouteTimeouts defines timeouts that can be configured for an HTTPRoute. +// Timeout values are formatted like 1h/1m/1s/1ms as parsed by Golang time.ParseDuration +// and MUST BE >= 1ms. +type HTTPRouteTimeouts struct { + // Request specifies an end-to-end timeout for client HTTP requests, + // disabled by default. + // + // For example, the following rule will wait no longer than 10 secs for the + // client request to complete: + // + // ``` + // rules: + // - timeouts: + // request: 10s + // backendRefs: + // ... + // ``` + // + // Support: Core + // + // +optional + Request *metav1.Duration `json:"request,omitempty"` + + // BackendRequest specifies a timeout for an individual request to a backend service. + // Default is the value of Request timeout. + // + // Support: Extended + // + // +optional + BackendRequest *metav1.Duration `json:"backendRequest,omitempty"` } ``` @@ -353,47 +378,23 @@ spec: - backendRefs: - name: some-service port: 8080 - timeout: 10s - retries: - attempts: 3 - perTryTimeout: 2s - retryOn: [ "503" ] + timeouts: + request: 10s + backendRequest: 2s ``` ### Timeout values -Timeout and PerTryTimeout values are formatted as 1h/1m/1s/1ms and MUST BE >= 1ms. - -### Retry attempts - -By default, the number of retry attempts is implementation dependent. An implementation MAY -provide external mechanisims for controlling the default retry behavior. - -When a request Timeout in the HTTPRouteRule or PerTryTimeout value is configured, the actual -number of retries attempted may be reduced depending on the specified request Timeout and -PerTryTimeout values. - -An implementation MUST ensure that the number of retries never exceeds the Attempts value, -if specified. - -The interval between retries is implementation dependent but SHOULD be a minimum of 25ms. - -### RetryOn Conditions - -The value of an individual RetryOn condition can be either an HTTP status codes (e.g., 503) -or some other identifier known to the implementation. - -An implementation MUST support any HTTP status code value for a RetryOn condition. +There a 2 kinds of timeouts that can be configured in an `HTTPRouteRule`: -The default conditions that will trigger retries, if no RetryOn conditions are specified, -is implementation dependent. +1. `timeouts.request` is an end-to-end timeout for a single request as measured by the client. + This field is required `Core` support. -### RetryRemoteLocalities +1. `timeouts.backendRequest` is a timeout for a single backend request as measured by the gateway, not the client. + This field is optional `Extended` support. Typically used in conjuction with retry configuration, if supported + by an implementation. Note that retry configuration will be the subject of a separate GEP (GEP-1731). -When an implementation supports prioritizing endpoints based on their locations, this field -can be used to control whether or not retry attempts should only select endpoints with the -same priority (RetryRemoteLocalities=false) or any healthy endpoint, regardless of location -(RetryRemoteLocalities=true). +Both timeout fields are string duration values as specified by ISO 8601 and MUST be >= 1ms. ## Alternatives From 09ca210f1f385169434fb79cc09c7d45f55d44b7 Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Tue, 16 May 2023 15:33:18 -0400 Subject: [PATCH 04/27] clarify and add diagram --- geps/gep-1742.md | 54 ++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 43 insertions(+), 11 deletions(-) diff --git a/geps/gep-1742.md b/geps/gep-1742.md index 89e661e69e..abdee28fd5 100644 --- a/geps/gep-1742.md +++ b/geps/gep-1742.md @@ -314,7 +314,7 @@ rules. This is a relatively small addition that would benefit many users. A client HTTP request to a gateway may result in more than one call to the destination backend service, for example, if automatic retries are supported. Some implementations support configuring a timeout for the individual backend requests, seperate from the -overall client request timeout. Adding None-Core support for this would also benefit +overall client request timeout. Adding non-Core support for this would also benefit many users. ### GO @@ -336,11 +336,11 @@ type HTTPRouteRule struct { // Timeout values are formatted like 1h/1m/1s/1ms as parsed by Golang time.ParseDuration // and MUST BE >= 1ms. type HTTPRouteTimeouts struct { - // Request specifies an end-to-end timeout for client HTTP requests, - // disabled by default. + // Request specifies a timeout for responding to client HTTP requests, + // disabled by default. // - // For example, the following rule will wait no longer than 10 secs for the - // client request to complete: + // For example, the following rule will timeout if a client request is taking + // longer than 10 seconds to complete: // // ``` // rules: @@ -355,8 +355,9 @@ type HTTPRouteTimeouts struct { // +optional Request *metav1.Duration `json:"request,omitempty"` - // BackendRequest specifies a timeout for an individual request to a backend service. - // Default is the value of Request timeout. + // BackendRequest specifies a timeout for an individual request from the gateway + // to a backend service. + // Default is the value of Request timeout. // // Support: Extended // @@ -387,12 +388,43 @@ spec: There a 2 kinds of timeouts that can be configured in an `HTTPRouteRule`: -1. `timeouts.request` is an end-to-end timeout for a single request as measured by the client. +1. `timeouts.request` is the timeout for the Gateway API implementation to send a + response to a client HTTP request. Whether the gateway starts the timeout before + or after the entire client request stream has been received, is implementation dependent. This field is required `Core` support. -1. `timeouts.backendRequest` is a timeout for a single backend request as measured by the gateway, not the client. - This field is optional `Extended` support. Typically used in conjuction with retry configuration, if supported - by an implementation. Note that retry configuration will be the subject of a separate GEP (GEP-1731). +1. `timeouts.backendRequest` is a timeout for a single request from the gateway to a backend. + This field is optional `Extended` support. Typically used in conjuction with retry configuration, + if supported by an implementation. + Note that retry configuration will be the subject of a separate GEP (GEP-1731). + +```mermaid +sequenceDiagram + participant C as Client + participant P as Proxy + participant U as Upstream + C->>P: Connection Started + note left of P: timeouts.request start time (min) + C->>P: Starts sending Request + C->>P: Finishes Headers + note left of P: timeouts.request start time (max) + C->>P: Finishes request + P->>U: Connection Started + note right of P: timeouts.backendRequest start time + P->>U: Starts sending Request + P->>U: Finishes request + P->>U: Finishes Headers + U->>P: Starts Response + U->>P: Finishes Headers + note right of P: timeouts.backendRequest timeout + U->>P: Finishes Response + note left of P: timeouts.request timout + P->>C: Starts Response + P->>C: Finishes Headers + P->>C: Finishes Response + Note right of P: Repeat if connection sharing + U->>C: Connection ended +``` Both timeout fields are string duration values as specified by ISO 8601 and MUST be >= 1ms. From 18b6894491bbbea6d5ae9634e98b2c1a7784d058 Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Tue, 16 May 2023 15:42:42 -0400 Subject: [PATCH 05/27] tweak diagram --- geps/gep-1742.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/geps/gep-1742.md b/geps/gep-1742.md index abdee28fd5..adf7e9d858 100644 --- a/geps/gep-1742.md +++ b/geps/gep-1742.md @@ -417,8 +417,9 @@ sequenceDiagram U->>P: Starts Response U->>P: Finishes Headers note right of P: timeouts.backendRequest timeout - U->>P: Finishes Response note left of P: timeouts.request timout + U->>P: Finishes Response + note left of P: Repeat if retry P->>C: Starts Response P->>C: Finishes Headers P->>C: Finishes Response From 2799811f208f1535f5f404495dfa793828d2bb0e Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Tue, 16 May 2023 15:49:14 -0400 Subject: [PATCH 06/27] tweak diagram --- geps/gep-1742.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-1742.md b/geps/gep-1742.md index adf7e9d858..2142d49b10 100644 --- a/geps/gep-1742.md +++ b/geps/gep-1742.md @@ -419,7 +419,7 @@ sequenceDiagram note right of P: timeouts.backendRequest timeout note left of P: timeouts.request timout U->>P: Finishes Response - note left of P: Repeat if retry + note right of P: Repeat if retry P->>C: Starts Response P->>C: Finishes Headers P->>C: Finishes Response From 90606a864a21c81f9db9c4d99b63e3fa25c37895 Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Tue, 16 May 2023 15:56:08 -0400 Subject: [PATCH 07/27] formatting --- geps/gep-1742.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/geps/gep-1742.md b/geps/gep-1742.md index 2142d49b10..55d5d427e8 100644 --- a/geps/gep-1742.md +++ b/geps/gep-1742.md @@ -307,7 +307,7 @@ Although there may be opportunity for the specification of a common API for more them in the future, this GEP will focus on the L7 timeouts in HTTPRoutes that are most valuable to clients. -From the above analysis, it appears that most (all?) implementations are capable of +From the above analysis, it appears that, at a minimum, implementations are capable of supporting the configuration of simple client downstream request timeouts on HTTPRoute rules. This is a relatively small addition that would benefit many users. @@ -337,7 +337,7 @@ type HTTPRouteRule struct { // and MUST BE >= 1ms. type HTTPRouteTimeouts struct { // Request specifies a timeout for responding to client HTTP requests, - // disabled by default. + // disabled by default. // // For example, the following rule will timeout if a client request is taking // longer than 10 seconds to complete: @@ -356,8 +356,8 @@ type HTTPRouteTimeouts struct { Request *metav1.Duration `json:"request,omitempty"` // BackendRequest specifies a timeout for an individual request from the gateway - // to a backend service. - // Default is the value of Request timeout. + // to a backend service. + // Default is the value of Request timeout. // // Support: Extended // From f07a25926fa402deb13e5ea0e5c9588d79405e6a Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Tue, 16 May 2023 16:35:27 -0400 Subject: [PATCH 08/27] timeout -> end time --- geps/gep-1742.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/geps/gep-1742.md b/geps/gep-1742.md index 55d5d427e8..9eb13d54b7 100644 --- a/geps/gep-1742.md +++ b/geps/gep-1742.md @@ -416,8 +416,8 @@ sequenceDiagram P->>U: Finishes Headers U->>P: Starts Response U->>P: Finishes Headers - note right of P: timeouts.backendRequest timeout - note left of P: timeouts.request timout + note right of P: timeouts.backendRequest end time + note left of P: timeouts.request end time U->>P: Finishes Response note right of P: Repeat if retry P->>C: Starts Response From ad0e9c7a569bde169254a47a68e7f760ad6ebb15 Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Wed, 17 May 2023 17:26:45 -0400 Subject: [PATCH 09/27] duration format --- geps/gep-1742.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/geps/gep-1742.md b/geps/gep-1742.md index 9eb13d54b7..20bc6f4240 100644 --- a/geps/gep-1742.md +++ b/geps/gep-1742.md @@ -427,7 +427,8 @@ sequenceDiagram U->>C: Connection ended ``` -Both timeout fields are string duration values as specified by ISO 8601 and MUST be >= 1ms. +Both timeout fields are string duration values as specified by +[Golang time.ParseDuration](https://pkg.go.dev/time#ParseDuration) and MUST be >= 1ms. ## Alternatives From db6688b96bd9ac51802cdb3994ddb7cc1b5d8208 Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Wed, 24 May 2023 11:59:39 -0400 Subject: [PATCH 10/27] address review comments --- geps/gep-1742.md | 68 ++++++++++++++++++++++++++++++++++-------------- 1 file changed, 48 insertions(+), 20 deletions(-) diff --git a/geps/gep-1742.md b/geps/gep-1742.md index 20bc6f4240..b1d8afe496 100644 --- a/geps/gep-1742.md +++ b/geps/gep-1742.md @@ -1,7 +1,7 @@ # GEP-1742: Timeouts * Issue: [#1742](https://github.com/kubernetes-sigs/gateway-api/issues/1742) -* Status: Provisional +* Status: Implementable (See status definitions [here](overview.md#status).) @@ -12,12 +12,12 @@ timeouts for different types of connection. ## Goals -- Create some method to configure some timeouts +- Create some method to configure some timeouts. - Timeout config must be applicable to most if not all Gateway API implementations. ## Non-Goals -- TBD +- A standard API for every possible timeout that implementations may support. ## Introduction @@ -336,32 +336,32 @@ type HTTPRouteRule struct { // Timeout values are formatted like 1h/1m/1s/1ms as parsed by Golang time.ParseDuration // and MUST BE >= 1ms. type HTTPRouteTimeouts struct { - // Request specifies a timeout for responding to client HTTP requests, - // disabled by default. + // Request specifies a timeout for the Gateway to send a response to a client HTTP request. + // Whether the gateway starts the timeout before or after the entire client request stream + // has been received, is implementation dependent. // - // For example, the following rule will timeout if a client request is taking - // longer than 10 seconds to complete: + // For example, setting the `rules.timeouts.request` field to the value `10s` in an + // `HTTPRoute` will cause a timeout if a client request is taking longer than 10 seconds + // to complete. // - // ``` - // rules: - // - timeouts: - // request: 10s - // backendRefs: - // ... - // ``` + // Request timeouts are disabled by default. // // Support: Core // // +optional - Request *metav1.Duration `json:"request,omitempty"` + // +kubebuilder:validation:Format=duration + Request *metav1.Duration `json:"request,omitempty"` // BackendRequest specifies a timeout for an individual request from the gateway - // to a backend service. + // to a backend service. Typically used in conjuction with retry configuration, + // if supported by an implementation. + // // Default is the value of Request timeout. // // Support: Extended // // +optional + // +kubebuilder:validation:Format=duration BackendRequest *metav1.Duration `json:"backendRequest,omitempty"` } ``` @@ -386,7 +386,7 @@ spec: ### Timeout values -There a 2 kinds of timeouts that can be configured in an `HTTPRouteRule`: +There are 2 kinds of timeouts that can be configured in an `HTTPRouteRule`: 1. `timeouts.request` is the timeout for the Gateway API implementation to send a response to a client HTTP request. Whether the gateway starts the timeout before @@ -407,8 +407,8 @@ sequenceDiagram note left of P: timeouts.request start time (min) C->>P: Starts sending Request C->>P: Finishes Headers - note left of P: timeouts.request start time (max) C->>P: Finishes request + note left of P: timeouts.request start time (max) P->>U: Connection Started note right of P: timeouts.backendRequest start time P->>U: Starts sending Request @@ -432,8 +432,36 @@ Both timeout fields are string duration values as specified by ## Alternatives -(List other design alternatives and why we did not go in that -direction) +Timeouts could be configure using policy attachments or using resources other than `HTTPRouteRule`. + +### Policy Attachment + +Instead of configuring timeouts directly on an API resource, they could be configured using policy +attachements. The advanatage to this approach would be that timeout policies can not only be +configured for an `HTTPRouteRule`, but can also be added/overriden at a more fine +(e.g., `HTTPBackendRef`) or course (e.g. `HTTPRoute`) level of granularity. + +The downside, however, is complexity introduced for the most common use case, adding a simple +tiemout for an HTTP request. Setting a single field in the route rule, instead of needing to +create a policy resource, for this simple case seems much better. + +Note that in the future, we could use policy attachements to configure other kinds of less common +timeouts that may be needed. The default values of the proposed timeout fields could also be overriden +using policy attachments in the future. For example, a policy attachment could be used to set the +default value of `rules.timeouts.request` for all routes under an `HTTPRoute` or `Gateway`. + +### Other API Resources + +The new timeouts field could be added to a different API resource, instead of `HTTPRouteRule`. + +Putting it on an `HTTPBackendRef`, for example, would allow users to set different timeouts for different +backends. This is a feature that we believe has not been requested by existing service mesh clients +and is also not easily implementable. + +Another alternative is to move the timeouts configuration up a level in the API to `HTTPRoute`. This +would be convenient when a user wants the same timeout on all rules, but would be overly restrictive. +Using policy attachements to override the default timemout value for all rules, as described in the +previous section, is likely a better way to handle timeout configuration above the route rule level. ## References From 224d34250a73e37bd06d3a39b8fa4acabb8b4699 Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Wed, 24 May 2023 12:07:30 -0400 Subject: [PATCH 11/27] fix format --- geps/gep-1742.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-1742.md b/geps/gep-1742.md index b1d8afe496..68c0e170dc 100644 --- a/geps/gep-1742.md +++ b/geps/gep-1742.md @@ -361,7 +361,7 @@ type HTTPRouteTimeouts struct { // Support: Extended // // +optional - // +kubebuilder:validation:Format=duration + // +kubebuilder:validation:Format=duration BackendRequest *metav1.Duration `json:"backendRequest,omitempty"` } ``` From 7a01f3ed25599d14c97ac3a58199960d2777a50a Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Wed, 24 May 2023 12:15:31 -0400 Subject: [PATCH 12/27] spelling --- geps/gep-1742.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/geps/gep-1742.md b/geps/gep-1742.md index 68c0e170dc..8f259dc77e 100644 --- a/geps/gep-1742.md +++ b/geps/gep-1742.md @@ -437,7 +437,7 @@ Timeouts could be configure using policy attachments or using resources other th ### Policy Attachment Instead of configuring timeouts directly on an API resource, they could be configured using policy -attachements. The advanatage to this approach would be that timeout policies can not only be +attachments. The advanatage to this approach would be that timeout policies can not only be configured for an `HTTPRouteRule`, but can also be added/overriden at a more fine (e.g., `HTTPBackendRef`) or course (e.g. `HTTPRoute`) level of granularity. @@ -445,7 +445,7 @@ The downside, however, is complexity introduced for the most common use case, ad tiemout for an HTTP request. Setting a single field in the route rule, instead of needing to create a policy resource, for this simple case seems much better. -Note that in the future, we could use policy attachements to configure other kinds of less common +Note that in the future, we could use policy attachments to configure other kinds of less common timeouts that may be needed. The default values of the proposed timeout fields could also be overriden using policy attachments in the future. For example, a policy attachment could be used to set the default value of `rules.timeouts.request` for all routes under an `HTTPRoute` or `Gateway`. @@ -460,7 +460,7 @@ and is also not easily implementable. Another alternative is to move the timeouts configuration up a level in the API to `HTTPRoute`. This would be convenient when a user wants the same timeout on all rules, but would be overly restrictive. -Using policy attachements to override the default timemout value for all rules, as described in the +Using policy attachments to override the default timeout value for all rules, as described in the previous section, is likely a better way to handle timeout configuration above the route rule level. ## References From 29cc9f002f573ba64147ef62a9116136ba25e12f Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Wed, 24 May 2023 13:26:17 -0400 Subject: [PATCH 13/27] Update geps/gep-1742.md Co-authored-by: Shane Utt --- geps/gep-1742.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-1742.md b/geps/gep-1742.md index 8f259dc77e..56dbc387d5 100644 --- a/geps/gep-1742.md +++ b/geps/gep-1742.md @@ -1,7 +1,7 @@ # GEP-1742: Timeouts * Issue: [#1742](https://github.com/kubernetes-sigs/gateway-api/issues/1742) -* Status: Implementable +* Status: Provisional (See status definitions [here](overview.md#status).) From 26e451adbc3b642ed379ff99cebf6dc773fb3499 Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Wed, 24 May 2023 13:35:18 -0400 Subject: [PATCH 14/27] fix tab --- geps/gep-1742.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/geps/gep-1742.md b/geps/gep-1742.md index 56dbc387d5..b5edad8112 100644 --- a/geps/gep-1742.md +++ b/geps/gep-1742.md @@ -350,7 +350,7 @@ type HTTPRouteTimeouts struct { // // +optional // +kubebuilder:validation:Format=duration - Request *metav1.Duration `json:"request,omitempty"` + Request *metav1.Duration `json:"request,omitempty"` // BackendRequest specifies a timeout for an individual request from the gateway // to a backend service. Typically used in conjuction with retry configuration, @@ -442,7 +442,7 @@ configured for an `HTTPRouteRule`, but can also be added/overriden at a more fin (e.g., `HTTPBackendRef`) or course (e.g. `HTTPRoute`) level of granularity. The downside, however, is complexity introduced for the most common use case, adding a simple -tiemout for an HTTP request. Setting a single field in the route rule, instead of needing to +timeout for an HTTP request. Setting a single field in the route rule, instead of needing to create a policy resource, for this simple case seems much better. Note that in the future, we could use policy attachments to configure other kinds of less common From 7b6315beb9c9d9b2f9fec2dab7e7fd94437085c9 Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Wed, 24 May 2023 16:37:12 -0400 Subject: [PATCH 15/27] tweak wording --- geps/gep-1742.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/geps/gep-1742.md b/geps/gep-1742.md index b5edad8112..d160086433 100644 --- a/geps/gep-1742.md +++ b/geps/gep-1742.md @@ -432,11 +432,11 @@ Both timeout fields are string duration values as specified by ## Alternatives -Timeouts could be configure using policy attachments or using resources other than `HTTPRouteRule`. +Timeouts could be configured using policy attachments or in objects other than `HTTPRouteRule`. ### Policy Attachment -Instead of configuring timeouts directly on an API resource, they could be configured using policy +Instead of configuring timeouts directly on an API object, they could be configured using policy attachments. The advanatage to this approach would be that timeout policies can not only be configured for an `HTTPRouteRule`, but can also be added/overriden at a more fine (e.g., `HTTPBackendRef`) or course (e.g. `HTTPRoute`) level of granularity. @@ -450,13 +450,13 @@ timeouts that may be needed. The default values of the proposed timeout fields c using policy attachments in the future. For example, a policy attachment could be used to set the default value of `rules.timeouts.request` for all routes under an `HTTPRoute` or `Gateway`. -### Other API Resources +### Other API Objects -The new timeouts field could be added to a different API resource, instead of `HTTPRouteRule`. +The new timeouts field could be added to a different API struct, instead of `HTTPRouteRule`. Putting it on an `HTTPBackendRef`, for example, would allow users to set different timeouts for different -backends. This is a feature that we believe has not been requested by existing service mesh clients -and is also not easily implementable. +backends. This is a feature that we believe has not been requested by existing proxy or service mesh +clients and is also not easily implementable. Another alternative is to move the timeouts configuration up a level in the API to `HTTPRoute`. This would be convenient when a user wants the same timeout on all rules, but would be overly restrictive. From bef97ed81e55892ecadd9f19f60a2db6a173b476 Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Thu, 25 May 2023 15:19:38 -0400 Subject: [PATCH 16/27] more review comments --- geps/gep-1742.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/geps/gep-1742.md b/geps/gep-1742.md index d160086433..18285b5c97 100644 --- a/geps/gep-1742.md +++ b/geps/gep-1742.md @@ -311,11 +311,11 @@ From the above analysis, it appears that, at a minimum, implementations are capa supporting the configuration of simple client downstream request timeouts on HTTPRoute rules. This is a relatively small addition that would benefit many users. -A client HTTP request to a gateway may result in more than one call to the destination -backend service, for example, if automatic retries are supported. Some implementations -support configuring a timeout for the individual backend requests, seperate from the -overall client request timeout. Adding non-Core support for this would also benefit -many users. +Some implementations support configuring a timeout for individual backend requests, +separate from the overall client request timeout. This is particularly useful if a +client HTTP request to a gateway can result in more than one call from the gateway +to the destination backend service, for example, if automatic retries are supported. +Adding non-Core support for this would also benefit many users. ### GO @@ -356,7 +356,7 @@ type HTTPRouteTimeouts struct { // to a backend service. Typically used in conjuction with retry configuration, // if supported by an implementation. // - // Default is the value of Request timeout. + // The value of BackendRequest defaults to and must be <= the value of Request timeout. // // Support: Extended // From 7e20c3d25368b2c91d0952dfbd842f46e3324b36 Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Tue, 30 May 2023 14:37:39 -0400 Subject: [PATCH 17/27] clarify --- geps/gep-1742.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/geps/gep-1742.md b/geps/gep-1742.md index 18285b5c97..58da1eaffd 100644 --- a/geps/gep-1742.md +++ b/geps/gep-1742.md @@ -336,15 +336,16 @@ type HTTPRouteRule struct { // Timeout values are formatted like 1h/1m/1s/1ms as parsed by Golang time.ParseDuration // and MUST BE >= 1ms. type HTTPRouteTimeouts struct { - // Request specifies a timeout for the Gateway to send a response to a client HTTP request. + // Request specifies the duration for processing an HTTP client request after which the + // gateway will time out if unable to send a response. // Whether the gateway starts the timeout before or after the entire client request stream - // has been received, is implementation dependent. + // has been received, is implementation-dependent. // // For example, setting the `rules.timeouts.request` field to the value `10s` in an // `HTTPRoute` will cause a timeout if a client request is taking longer than 10 seconds // to complete. // - // Request timeouts are disabled by default. + // When this field is unspecified, request timeout behavior is implementation-dependent. // // Support: Core // From 650874de32a1823c007d3da11fdaa0b8a27f982b Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Wed, 31 May 2023 13:35:22 -0400 Subject: [PATCH 18/27] Update geps/gep-1742.md Co-authored-by: Candace Holman --- geps/gep-1742.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-1742.md b/geps/gep-1742.md index 58da1eaffd..6021b617fe 100644 --- a/geps/gep-1742.md +++ b/geps/gep-1742.md @@ -438,7 +438,7 @@ Timeouts could be configured using policy attachments or in objects other than ` ### Policy Attachment Instead of configuring timeouts directly on an API object, they could be configured using policy -attachments. The advanatage to this approach would be that timeout policies can not only be +attachments. The advantage to this approach would be that timeout policies can be not only configured for an `HTTPRouteRule`, but can also be added/overriden at a more fine (e.g., `HTTPBackendRef`) or course (e.g. `HTTPRoute`) level of granularity. From 659d478ec039271a95429b133a999d1593808e96 Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Wed, 31 May 2023 14:46:18 -0400 Subject: [PATCH 19/27] updates --- geps/gep-1742.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/geps/gep-1742.md b/geps/gep-1742.md index 6021b617fe..f7997e23b6 100644 --- a/geps/gep-1742.md +++ b/geps/gep-1742.md @@ -334,7 +334,7 @@ type HTTPRouteRule struct { // HTTPRouteTimeouts defines timeouts that can be configured for an HTTPRoute. // Timeout values are formatted like 1h/1m/1s/1ms as parsed by Golang time.ParseDuration -// and MUST BE >= 1ms. +// and MUST BE >= 1ms or 0 to disable (no timeout). type HTTPRouteTimeouts struct { // Request specifies the duration for processing an HTTP client request after which the // gateway will time out if unable to send a response. @@ -429,7 +429,8 @@ sequenceDiagram ``` Both timeout fields are string duration values as specified by -[Golang time.ParseDuration](https://pkg.go.dev/time#ParseDuration) and MUST be >= 1ms. +[Golang time.ParseDuration](https://pkg.go.dev/time#ParseDuration) and MUST be >= 1ms +or 0 to disable (no timeout). ## Alternatives @@ -446,8 +447,11 @@ The downside, however, is complexity introduced for the most common use case, ad timeout for an HTTP request. Setting a single field in the route rule, instead of needing to create a policy resource, for this simple case seems much better. -Note that in the future, we could use policy attachments to configure other kinds of less common -timeouts that may be needed. The default values of the proposed timeout fields could also be overriden +In the future, we could consider using policy attachments to configure less common kinds of +timeouts that may be needed, but it would probably be better to instead extend the proposed API +to support those timeouts as well. + +The default values of the proposed timeout fields could also be overriden using policy attachments in the future. For example, a policy attachment could be used to set the default value of `rules.timeouts.request` for all routes under an `HTTPRoute` or `Gateway`. From 3c0e8e6a9134da60ef395e20ac309893ea12a2eb Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Wed, 31 May 2023 17:03:25 -0400 Subject: [PATCH 20/27] reword not easily implementable --- geps/gep-1742.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-1742.md b/geps/gep-1742.md index f7997e23b6..ba97bca285 100644 --- a/geps/gep-1742.md +++ b/geps/gep-1742.md @@ -461,7 +461,7 @@ The new timeouts field could be added to a different API struct, instead of `HTT Putting it on an `HTTPBackendRef`, for example, would allow users to set different timeouts for different backends. This is a feature that we believe has not been requested by existing proxy or service mesh -clients and is also not easily implementable. +clients and is also not implementable using available timeouts of most proxies. Another alternative is to move the timeouts configuration up a level in the API to `HTTPRoute`. This would be convenient when a user wants the same timeout on all rules, but would be overly restrictive. From 6c01fa8f375a974d1d69c1eb29c596e454b35205 Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Fri, 2 Jun 2023 11:37:24 -0400 Subject: [PATCH 21/27] less vague --- geps/gep-1742.md | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/geps/gep-1742.md b/geps/gep-1742.md index ba97bca285..afaf076a87 100644 --- a/geps/gep-1742.md +++ b/geps/gep-1742.md @@ -338,13 +338,16 @@ type HTTPRouteRule struct { type HTTPRouteTimeouts struct { // Request specifies the duration for processing an HTTP client request after which the // gateway will time out if unable to send a response. - // Whether the gateway starts the timeout before or after the entire client request stream - // has been received, is implementation-dependent. // // For example, setting the `rules.timeouts.request` field to the value `10s` in an // `HTTPRoute` will cause a timeout if a client request is taking longer than 10 seconds // to complete. // + // This timeout is intended to cover as close to the whole request-response transaction + // as possible although an implementation MAY choose to start the timeout after the entire + // request stream has been received instead of immediately after the transaction is + // initiated by the client. + // // When this field is unspecified, request timeout behavior is implementation-dependent. // // Support: Core @@ -354,10 +357,14 @@ type HTTPRouteTimeouts struct { Request *metav1.Duration `json:"request,omitempty"` // BackendRequest specifies a timeout for an individual request from the gateway - // to a backend service. Typically used in conjuction with retry configuration, - // if supported by an implementation. + // to a backend service. + // + // An entire client HTTP transaction with a gateway, covered by the Request timeout, + // can result in more than one call from the gateway to the destination backend service, + // for example, if automatic retries are supported. // - // The value of BackendRequest defaults to and must be <= the value of Request timeout. + // Because the Request timeout encompasses the BackendRequest timeout, + // the value of BackendRequest defaults to and must be <= the value of Request timeout. // // Support: Extended // From 4e7c538960812ecde3ecc574d22f6c1b92f4720b Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Mon, 5 Jun 2023 17:21:16 -0400 Subject: [PATCH 22/27] address review comments --- geps/gep-1742.md | 100 +++++++++++++++++++++++------------------------ 1 file changed, 50 insertions(+), 50 deletions(-) diff --git a/geps/gep-1742.md b/geps/gep-1742.md index afaf076a87..4cfcf7c1ea 100644 --- a/geps/gep-1742.md +++ b/geps/gep-1742.md @@ -298,7 +298,6 @@ Could not find any HTTP specific timeouts. PRs welcomed. 😊 Could not find any HTTP specific timeouts. PRs welcomed. 😊 - ## API The above diagrams show that there are many different kinds of configurable timeouts @@ -317,6 +316,53 @@ client HTTP request to a gateway can result in more than one call from the gatew to the destination backend service, for example, if automatic retries are supported. Adding non-Core support for this would also benefit many users. +### Timeout values + +There are 2 kinds of timeouts that can be configured in an `HTTPRouteRule`: + +1. `timeouts.request` is the timeout for the Gateway API implementation to send a + response to a client HTTP request. Whether the gateway starts the timeout before + or after the entire client request stream has been received, is implementation dependent. + This field is required `Core` support. + +1. `timeouts.backendRequest` is a timeout for a single request from the gateway to a backend. + This field is optional `Extended` support. Typically used in conjuction with retry configuration, + if supported by an implementation. + Note that retry configuration will be the subject of a separate GEP (GEP-1731). + +```mermaid +sequenceDiagram + participant C as Client + participant P as Proxy + participant U as Upstream + C->>P: Connection Started + note left of P: timeouts.request start time (min) + C->>P: Starts sending Request + C->>P: Finishes Headers + C->>P: Finishes request + note left of P: timeouts.request start time (max) + P->>U: Connection Started + note right of P: timeouts.backendRequest start time + P->>U: Starts sending Request + P->>U: Finishes request + P->>U: Finishes Headers + U->>P: Starts Response + U->>P: Finishes Headers + note right of P: timeouts.backendRequest end time + note left of P: timeouts.request end time + U->>P: Finishes Response + note right of P: Repeat if retry + P->>C: Starts Response + P->>C: Finishes Headers + P->>C: Finishes Response + Note right of P: Repeat if connection sharing + U->>C: Connection ended +``` + +Both timeout fields are string duration values as specified by +[Golang time.ParseDuration](https://pkg.go.dev/time#ParseDuration) and MUST be >= 1ms +or 0 to disable (no timeout). + ### GO ```go @@ -357,10 +403,11 @@ type HTTPRouteTimeouts struct { Request *metav1.Duration `json:"request,omitempty"` // BackendRequest specifies a timeout for an individual request from the gateway - // to a backend service. + // to a backend service. This covers the time from when the request firrst starts being + // sent from the gateway to when the full response has been received from the backend. // // An entire client HTTP transaction with a gateway, covered by the Request timeout, - // can result in more than one call from the gateway to the destination backend service, + // may result in more than one call from the gateway to the destination backend service, // for example, if automatic retries are supported. // // Because the Request timeout encompasses the BackendRequest timeout, @@ -392,53 +439,6 @@ spec: backendRequest: 2s ``` -### Timeout values - -There are 2 kinds of timeouts that can be configured in an `HTTPRouteRule`: - -1. `timeouts.request` is the timeout for the Gateway API implementation to send a - response to a client HTTP request. Whether the gateway starts the timeout before - or after the entire client request stream has been received, is implementation dependent. - This field is required `Core` support. - -1. `timeouts.backendRequest` is a timeout for a single request from the gateway to a backend. - This field is optional `Extended` support. Typically used in conjuction with retry configuration, - if supported by an implementation. - Note that retry configuration will be the subject of a separate GEP (GEP-1731). - -```mermaid -sequenceDiagram - participant C as Client - participant P as Proxy - participant U as Upstream - C->>P: Connection Started - note left of P: timeouts.request start time (min) - C->>P: Starts sending Request - C->>P: Finishes Headers - C->>P: Finishes request - note left of P: timeouts.request start time (max) - P->>U: Connection Started - note right of P: timeouts.backendRequest start time - P->>U: Starts sending Request - P->>U: Finishes request - P->>U: Finishes Headers - U->>P: Starts Response - U->>P: Finishes Headers - note right of P: timeouts.backendRequest end time - note left of P: timeouts.request end time - U->>P: Finishes Response - note right of P: Repeat if retry - P->>C: Starts Response - P->>C: Finishes Headers - P->>C: Finishes Response - Note right of P: Repeat if connection sharing - U->>C: Connection ended -``` - -Both timeout fields are string duration values as specified by -[Golang time.ParseDuration](https://pkg.go.dev/time#ParseDuration) and MUST be >= 1ms -or 0 to disable (no timeout). - ## Alternatives Timeouts could be configured using policy attachments or in objects other than `HTTPRouteRule`. From 2a1c1782b358d9fb81d6625a1173083d8edd3f06 Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Tue, 6 Jun 2023 09:28:48 -0400 Subject: [PATCH 23/27] make timeouts support extended --- geps/gep-1742.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/geps/gep-1742.md b/geps/gep-1742.md index 4cfcf7c1ea..e7315c7f15 100644 --- a/geps/gep-1742.md +++ b/geps/gep-1742.md @@ -1,7 +1,7 @@ # GEP-1742: Timeouts * Issue: [#1742](https://github.com/kubernetes-sigs/gateway-api/issues/1742) -* Status: Provisional +* Status: Implementable (See status definitions [here](overview.md#status).) @@ -306,7 +306,7 @@ Although there may be opportunity for the specification of a common API for more them in the future, this GEP will focus on the L7 timeouts in HTTPRoutes that are most valuable to clients. -From the above analysis, it appears that, at a minimum, implementations are capable of +From the above analysis, it appears that most implementations are capable of supporting the configuration of simple client downstream request timeouts on HTTPRoute rules. This is a relatively small addition that would benefit many users. @@ -314,7 +314,7 @@ Some implementations support configuring a timeout for individual backend reques separate from the overall client request timeout. This is particularly useful if a client HTTP request to a gateway can result in more than one call from the gateway to the destination backend service, for example, if automatic retries are supported. -Adding non-Core support for this would also benefit many users. +Adding support for this would also benefit many users. ### Timeout values @@ -323,7 +323,7 @@ There are 2 kinds of timeouts that can be configured in an `HTTPRouteRule`: 1. `timeouts.request` is the timeout for the Gateway API implementation to send a response to a client HTTP request. Whether the gateway starts the timeout before or after the entire client request stream has been received, is implementation dependent. - This field is required `Core` support. + This field is optional `Extended` support. 1. `timeouts.backendRequest` is a timeout for a single request from the gateway to a backend. This field is optional `Extended` support. Typically used in conjuction with retry configuration, @@ -369,7 +369,7 @@ or 0 to disable (no timeout). type HTTPRouteRule struct { // Timeouts defines the timeouts that can be configured for an HTTP request. // - // Support: Core + // Support: Extended // // +optional // @@ -396,7 +396,7 @@ type HTTPRouteTimeouts struct { // // When this field is unspecified, request timeout behavior is implementation-dependent. // - // Support: Core + // Support: Extended // // +optional // +kubebuilder:validation:Format=duration From f9181ec942e953596e7d3d26e113dae1841b75f1 Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Tue, 6 Jun 2023 11:12:44 -0400 Subject: [PATCH 24/27] typo --- geps/gep-1742.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-1742.md b/geps/gep-1742.md index e7315c7f15..f4121b5c61 100644 --- a/geps/gep-1742.md +++ b/geps/gep-1742.md @@ -403,7 +403,7 @@ type HTTPRouteTimeouts struct { Request *metav1.Duration `json:"request,omitempty"` // BackendRequest specifies a timeout for an individual request from the gateway - // to a backend service. This covers the time from when the request firrst starts being + // to a backend service. This covers the time from when the request first starts being // sent from the gateway to when the full response has been received from the backend. // // An entire client HTTP transaction with a gateway, covered by the Request timeout, From 12c731a596c75620caba871289d61467a8da408f Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Tue, 13 Jun 2023 09:24:43 -0400 Subject: [PATCH 25/27] Update geps/gep-1742.md Co-authored-by: Rob Scott --- geps/gep-1742.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-1742.md b/geps/gep-1742.md index f4121b5c61..9440c1e152 100644 --- a/geps/gep-1742.md +++ b/geps/gep-1742.md @@ -1,4 +1,4 @@ -# GEP-1742: Timeouts +# GEP-1742: HTTPRoute Timeouts * Issue: [#1742](https://github.com/kubernetes-sigs/gateway-api/issues/1742) * Status: Implementable From ab8283de832f7cb5bebcb83a7df9caceffc81c83 Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Tue, 13 Jun 2023 09:40:22 -0400 Subject: [PATCH 26/27] move to implementable --- mkdocs.yml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/mkdocs.yml b/mkdocs.yml index 539b2ec0a2..c9ec8d9260 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -79,12 +79,13 @@ nav: - Declined: - geps/gep-735.md - Provisional: - - geps/gep-1742.md - - geps/gep-1426.md - geps/gep-1324.md - geps/gep-1282.md - Prototyping: - geps/gep-1709.md + - Implementable: + - geps/gep-1742.md + - geps/gep-1426.md - Experimental: - geps/gep-1748.md - geps/gep-1323.md From bad35becce77bd41e7511849d80ba8b1424ebe44 Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Wed, 14 Jun 2023 09:05:23 -0400 Subject: [PATCH 27/27] add feature names --- geps/gep-1742.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/geps/gep-1742.md b/geps/gep-1742.md index 9440c1e152..7f7d07603e 100644 --- a/geps/gep-1742.md +++ b/geps/gep-1742.md @@ -439,6 +439,14 @@ spec: backendRequest: 2s ``` +### Conformance Details + +Gateway implementations can indicate support for the optional behavior in this GEP using +the following feature names: + +- `HTTPRouteRequestTimeout`: supports `rules.timeouts.request` in an `HTTPRoute`. +- `HTTPRouteBackendTimeout`: supports `rules.timeouts.backendRequest` in an `HTTPRoute`. + ## Alternatives Timeouts could be configured using policy attachments or in objects other than `HTTPRouteRule`.