-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
[release-3.11] UPSTREAM: 68678: tighten maximum retry loop for aggregate api availability #21012
[release-3.11] UPSTREAM: 68678: tighten maximum retry loop for aggregate api availability #21012
Conversation
/retest |
we can queue this up for first z release. |
Multiple other bugs are suspected of being tied back to this. Even if this doesn't resolve the issue it leads to upgrades stalling for up to 1000s. Other non aggregated APIs are unresponsive around the same time, could this potentially cause a wider API degradation? |
No. It is strictly related to remote servers. |
That e2e test failure is https://bugzilla.redhat.com/show_bug.cgi?id=1630537 |
This is poorly tracked because it's one of many problems in the constellation of upgrade issues where the API becomes unreliable. https://bugzilla.redhat.com/show_bug.cgi?id=1623571 https://bugzilla.redhat.com/show_bug.cgi?id=1628881 is a bug assigned to the networking team where @squeed suggests that it now looks like it's failing due to api aggregation. There are probably others but I've lost track of them. |
thanks @sdodson since we have had to take some other prs, i am going to take this now as well. /approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: derekwaynecarr, openshift-cherrypick-robot 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 |
This is an automated cherry-pick of #20999
/assign deads2k