OCPBUGS-61858: Add HTTPKeepAliveTimeout to IngressController API #2547
Conversation
This commit introduces `HTTPKeepAliveTimeout` tuning option to the IngressController API, allowing customers to configure `timeout http-keep-alive`. In OCP versions prior to 4.16, this timeout was not respected (see haproxy/haproxy#2334). This addition brings the ability to adjust the behavior to match pre-4.16 configurations.
openshift-ci-robot
added
the
jira/severity-critical
|
Hello @alebedev87! Some important instructions when contributing to openshift/api: |
openshift-ci-robot
added
jira/valid-reference
|
@alebedev87: This pull request references Jira Issue OCPBUGS-61858, which is invalid:
Comment The bug has been updated to refer to the pull request using the external bug tracker. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci
bot
added
the
size/M
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@alebedev87: all tests passed! Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
/jira refresh |
openshift-ci-robot
added
the
jira/valid-bug
|
@alebedev87: This pull request references Jira Issue OCPBUGS-61858, which is valid. The bug has been moved to the POST state. 3 validation(s) were run on this bug
Requesting review from QA contact: In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci-robot
removed
the
jira/invalid-bug
| // httpKeepAliveTimeout defines the maximum allowed time to wait for | ||
| // a new HTTP request to appear. |
There was a problem hiding this comment.
This refers to waiting for a new HTTP request to appear on an idle connection that is being considered for closure, right? If that is the purpose, or one of the purposes of this timeout, it should be mentioned.
There was a problem hiding this comment.
Closure of an idle connection is one of the purposes. There are quite some others mentioned in the haproxy docs. I didn't want to favorise one over another or list them all (as there are many). I think this message is consitent with other timeouts we have.
| // fraction and a unit suffix, e.g. "300ms", "1.5h" or "2h45m". | ||
| // Valid time units are "ns", "us" (or "µs" U+00B5 or "μs" U+03BC), "ms", "s", "m", "h". | ||
| // | ||
| // When omitted, this means the user has no opinion and the platform is left |
There was a problem hiding this comment.
I think adding a section starting with "// Setting this field is generally not recommended..." is always helpful. We have it on most of the other tuning options to help people understand the consequence of changing the default value, with explanation for what happens if you set it too high (idle connections remain open longer and use unnecessary resources?), and what happens if you set it too low (idle connection could be closed sooner than wanted and interrupt traffic?).
There was a problem hiding this comment.
"// Setting this field is generally not recommended..."
I cannot say that it's "not recommended". It's a prerogative of a customer, that's why we had an RFE fo it. I can elaborate on corner cases though.
| // to choose a reasonable default. This default is subject to change over time. | ||
| // The current default is 300s. | ||
| // | ||
| // +kubebuilder:validation:Pattern=^(0|([0-9]+(\.[0-9]+)?(ns|us|µs|μs|ms|s|m|h))+)$ |
There was a problem hiding this comment.
// +kubebuilder:validation:Format=duration
does this works instead? spotted it on other field above
There was a problem hiding this comment.
Right, the duration validation is not aligned in the tuning options. I used the explicit regex for a reason that some kubebuilder's duration != golang's duration. We have a bug which showcases this for the client timeout.
However this made me think of the fact that I forgot to add tests for the new field, will do them.
| // +kubebuilder:validation:Pattern=^(0|([0-9]+(\.[0-9]+)?(ns|us|µs|μs|ms|s|m|h))+)$ | ||
| // +kubebuilder:validation:Type:=string | ||
| // +optional | ||
| HTTPKeepAliveTimeout *metav1.Duration `json:"httpKeepAliveTimeout,omitempty"` |
There was a problem hiding this comment.
Note
We prefer not to use duration values anymore. Instead, we would create a int32 type, with units in the name. For example, this should be httpKeepAliveTimeoutSeconds.
Referring linter: kubernetes-sigs/kube-api-linter#24
We have a bunch of other *metav1.Duration types as part of this structure and I think we should keep them consistent with the new field.
There was a problem hiding this comment.
We have a bunch of other *metav1.Duration types as part of this structure and I think we should keep them consistent with the new field.
I think this makes sense for new APIs (or new fields of existing APIs). But here I'm thinking of the consistency in the scope of the same API field. All other timeouts we have in IngressController.Spec.TuningOptions are metav1.Duration. Using httpKeepAliveTimeoutSeconds will break the existing pattern and harm the user experience. I acknowledge the new rule but I would like to stay consistent with other timeouts. Unless it's a hard requirement without which we won't get an approval from the API team.
5 participants
This PR introduces
HTTPKeepAliveTimeouttuning option to the IngressController API, allowing customers to configuretimeout http-keep-alive.In OCP versions prior to 4.16, this timeout was not respected (see haproxy/haproxy#2334). This addition brings the ability to adjust the behavior to match pre-4.16 configurations.
Xref old RFE: https://issues.redhat.com/browse/RFE-1284.