Skip to content

Conversation

cybertron
Copy link
Member

I'm not sure why we set these to 24 hours in the first place, but
it doesn't match what we document in our sample UPI HAProxy config,
nor can I find any justification for why one would want such long
timeouts. This changes our client and server timeouts to be 1m,
matching the documented values. It also sets the tunnel timeout to
5m, which is not covered at all in the documentation but according
to HAProxy docs should generally be longer than other timeouts since
tunnel connection tend to be longer lived.

- What I did

- How to verify it

- Description for the changelog

We have a bug where misbehaved clients are exhausting the connection
limits by starting a connection and abandoning it before it is even
established. Setting the client-fin timeout is a recommended option
to address this sort of situation. This patch also sets server-fin
in the interest of symmetry and avoiding any similar issues on the
server side.
I'm not sure why we set these to 24 hours in the first place, but
it doesn't match what we document in our sample UPI HAProxy config,
nor can I find any justification for why one would want such long
timeouts. This changes our client and server timeouts to be 1m,
matching the documented values. It also sets the tunnel timeout to
5m, which is not covered at all in the documentation but according
to HAProxy docs should generally be longer than other timeouts since
tunnel connection tend to be longer lived.
@openshift-ci openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Sep 26, 2025
Copy link
Contributor

openshift-ci bot commented Sep 26, 2025

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@openshift-ci-robot openshift-ci-robot added jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. jira/valid-bug Indicates that a referenced Jira bug is valid for the branch this PR is targeting. labels Sep 26, 2025
@openshift-ci-robot
Copy link
Contributor

@cybertron: This pull request references Jira Issue OCPBUGS-62295, which is valid. The bug has been moved to the POST state.

3 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target version (4.21.0) matches configured target version for branch (4.21.0)
  • bug is in the state New, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @rbbratta

The bug has been updated to refer to the pull request using the external bug tracker.

In response to this:

I'm not sure why we set these to 24 hours in the first place, but
it doesn't match what we document in our sample UPI HAProxy config,
nor can I find any justification for why one would want such long
timeouts. This changes our client and server timeouts to be 1m,
matching the documented values. It also sets the tunnel timeout to
5m, which is not covered at all in the documentation but according
to HAProxy docs should generally be longer than other timeouts since
tunnel connection tend to be longer lived.

- What I did

- How to verify it

- Description for the changelog

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 openshift-ci bot requested a review from rbbratta September 26, 2025 20:11
Copy link
Contributor

openshift-ci bot commented Sep 26, 2025

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: cybertron
Once this PR has been reviewed and has the lgtm label, please assign cheesesashimi for approval. For more information see the Code Review Process.

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@cybertron
Copy link
Member Author

This should merge after #5310 to avoid issues with backporting that PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. jira/valid-bug Indicates that a referenced Jira bug is valid for the branch this PR is targeting. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants