-
Notifications
You must be signed in to change notification settings - Fork 1.1k
OCPBUGS-54658: Increase pull-progress-timeout to 30s
#9108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OCPBUGS-54658: Increase pull-progress-timeout to 30s
#9108
Conversation
@saschagrunert: This pull request references Jira Issue OCPBUGS-54658, 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. |
/jira refresh |
@saschagrunert: This pull request references Jira Issue OCPBUGS-54658, 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: GitHub didn't allow me to request PR reviews from the following users: cpmeadors. Note that only cri-o members and repo collaborators can review this PR, and authors cannot review their own PRs. 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 kubernetes-sigs/prow repository. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #9108 +/- ##
==========================================
- Coverage 47.03% 47.03% -0.01%
==========================================
Files 160 160
Lines 23608 23608
==========================================
- Hits 11104 11103 -1
- Misses 11407 11408 +1
Partials 1097 1097 🚀 New features to boost your workflow:
|
/retest |
There are use cases where a higher timeout is required because zscaler scans all transfers. To fulfill those we now use a slightly higher default value. Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
ef02542
to
012b6cd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: saschagrunert, sohankunkerkar The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest |
/override ci/prow/ci-e2e-evented-pleg |
@saschagrunert: Overrode contexts on behalf of saschagrunert: ci/prow/ci-e2e-evented-pleg 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 kubernetes-sigs/prow repository. |
@saschagrunert: Jira Issue OCPBUGS-54658: All pull requests linked via external trackers have merged: Jira Issue OCPBUGS-54658 has been moved to the MODIFIED state. 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. |
/cherry-pick release-1.32 |
@saschagrunert: new pull request created: #9112 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 kubernetes-sigs/prow repository. |
@saschagrunert: new pull request created: #9113 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 kubernetes-sigs/prow repository. |
@saschagrunert: new pull request created: #9114 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 kubernetes-sigs/prow repository. |
@saschagrunert: new pull request created: #9115 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 kubernetes-sigs/prow repository. |
how did we come to this value? I'm unsure we want to do this for this one use case. 10s worked for years before we dropped it then made it configurable, why change now? It feels like the point of having it configurable is these bespoke solutions can set it themselves |
I have two examples where they stated that a higher timeout would be beneficial. We could also disable it by default. I thought having a custom configuration is not doable for managed cloud services downstream. |
Follow-up on cri-o#9108 and multiple requests to disable the timeout per default. Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
Follow-up on cri-o#9108 and multiple requests to disable the timeout per default. Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
I dug into it and this is wrong, it kinda worked for one year: 1a377cc |
Follow-up on cri-o#9108 and multiple requests to disable the timeout per default. Cherry-picked: 44d9073 Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
Follow-up on cri-o#9108 and multiple requests to disable the timeout per default. Cherry-picked: 44d9073 Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
Follow-up on cri-o#9108 and multiple requests to disable the timeout per default. Cherry-picked: 44d9073 Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
Follow-up on cri-o#9108 and multiple requests to disable the timeout per default. Cherry-picked: 44d9073 Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
There are use cases where a higher timeout is required because zscaler scans all transfers. To fulfill those we now use a slightly higher default value.
Which issue(s) this PR fixes:
None
Special notes for your reviewer:
Needs to be backported down to 1.29.
Does this PR introduce a user-facing change?