From 515eef409a15f321d52813c117182410e97352ee Mon Sep 17 00:00:00 2001 From: Andrew McDermott Date: Tue, 19 Nov 2024 09:31:18 +0000 Subject: [PATCH] DO NOT MERGE: make update (CRD) --- manifests/00-custom-resource-definition.yaml | 137 ++++++++++--------- 1 file changed, 70 insertions(+), 67 deletions(-) diff --git a/manifests/00-custom-resource-definition.yaml b/manifests/00-custom-resource-definition.yaml index 84836c025..17d639a09 100644 --- a/manifests/00-custom-resource-definition.yaml +++ b/manifests/00-custom-resource-definition.yaml @@ -109,73 +109,6 @@ spec: - clientCA - clientCertificatePolicy type: object - connectionTerminationPolicy: - description: |- - IdleConnectionTerminationPolicy maps directly to HAProxy's - idle-close-on-response option and controls whether HAProxy - keeps idle frontend connections open during a soft stop - (router reload). - - When set to "Immediate" (default in OpenShift 4.19), idle - connections are closed immediately during router reloads. - This ensures immediate propagation of route changes but may - impact clients sensitive to connection resets. - - When set to "Deferred", HAProxy will maintain idle - connections during a soft reload instead of closing them - immediately. These connections remain open until any of the - following occurs: - - - A new request is received on the connection, in which - case HAProxy handles it in the old process and closes - the connection after sending the response. New client - connections will use the updated HAProxy configuration. - - - HAProxy's `timeout http-keep-alive` duration expires - (300 seconds in OpenShift's configuration, not - configurable). - - - The client's keep-alive timeout expires, causing the - client to close the connection. - - Setting Deferred can help prevent errors in clients or load - balancers that do not properly handle connection resets. - Additionally, this option allows you to retain the pre-2.4 - HAProxy behaviour: in HAProxy version 2.2 (OpenShift - versions < 4.14), maintaining idle connections during a - soft reload was the default behaviour, but starting with - HAProxy 2.4, the default changed to closing idle - connections immediately. - - Important Consideration: - - - Using Deferred will result in temporary inconsistencies - for the first request on each persistent connection - after a route update and router reload. This request - will be processed by the old HAProxy process using its - old configuration. Subsequent requests will use the - updated configuration. - - Operational Considerations: - - - Keeping idle connections open during reloads may lead - to an accumulation of old HAProxy processes if - connections remain idle for extended periods, - especially in environments where frequent reloads - occur. - - - Consider monitoring the number of HAProxy processes in - the router pods when Deferred is set. - - - You may need to enable or adjust the - `ingress.operator.openshift.io/hard-stop-after` - duration (configured via an annotation on the - IngressController resource) in environments with - frequent reloads to prevent resource exhaustion. - enum: - - Immediate - - Deferred - type: string defaultCertificate: description: |- defaultCertificate is a reference to a secret containing the default @@ -1322,6 +1255,76 @@ spec: type: string type: object type: object + idleConnectionTerminationPolicy: + default: Immediate + description: |- + IdleConnectionTerminationPolicy maps directly to HAProxy's + idle-close-on-response option and controls whether HAProxy + keeps idle frontend connections open during a soft stop + (router reload). + + Allowed values for this field are "Immediate" and + "Deferred". The default value is "Immediate". + + When set to "Immediate", idle connections are closed + immediately during router reloads. This ensures immediate + propagation of route changes but may impact clients + sensitive to connection resets. + + When set to "Deferred", HAProxy will maintain idle + connections during a soft reload instead of closing them + immediately. These connections remain open until any of the + following occurs: + + - A new request is received on the connection, in which + case HAProxy handles it in the old process and closes + the connection after sending the response. + + - HAProxy's `timeout http-keep-alive` duration expires + (300 seconds in OpenShift's configuration, not + configurable). + + - The client's keep-alive timeout expires, causing the + client to close the connection. + + Setting Deferred can help prevent errors in clients or load + balancers that do not properly handle connection resets. + Additionally, this option allows you to retain the pre-2.4 + HAProxy behaviour: in HAProxy version 2.2 (OpenShift + versions < 4.14), maintaining idle connections during a + soft reload was the default behaviour, but starting with + HAProxy 2.4, the default changed to closing idle + connections immediately. + + Important Consideration: + + - Using Deferred will result in temporary inconsistencies + for the first request on each persistent connection + after a route update and router reload. This request + will be processed by the old HAProxy process using its + old configuration. Subsequent requests will use the + updated configuration. + + Operational Considerations: + + - Keeping idle connections open during reloads may lead + to an accumulation of old HAProxy processes if + connections remain idle for extended periods, + especially in environments where frequent reloads + occur. + + - Consider monitoring the number of HAProxy processes in + the router pods when Deferred is set. + + - You may need to enable or adjust the + `ingress.operator.openshift.io/hard-stop-after` + duration (configured via an annotation on the + IngressController resource) in environments with + frequent reloads to prevent resource exhaustion. + enum: + - Immediate + - Deferred + type: string logging: description: |- logging defines parameters for what should be logged where. If this