DNM: Test PR for ClusterBot, webhook readiness + rate limit#479
DNM: Test PR for ClusterBot, webhook readiness + rate limit#479MahnoorAsghar wants to merge 2 commits into
Conversation
Signed-off-by: MahnoorAsghar <masghar@redhat.com>
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 21 minutes and 45 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Repository: openshift/coderabbit/.coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: MahnoorAsghar The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
The default controller-runtime exponential rate limiter has a maximum delay of 1000 seconds (~16 minutes). During BMO startup there is a brief race between the reconcile loop becoming active and BMO's own validating-webhook Service endpoint being propagated: any BareMetalHost reconciliation that triggers a webhook call in that window gets a "no endpoints available" error. A burst of such errors is enough to drive the per-item exponential backoff to its ceiling, after which BMO silently waits up to 16 minutes before attempting the next reconcile even though the webhook has long since become reachable. Replace the default rate limiter with one that is otherwise identical but caps the per-item exponential delay at 30 seconds. This bounds the recovery window to at most one retry interval after the endpoint is propagated, matching the behaviour of other Metal3 controllers. Generated-by: Cursor, claude-4.6-sonnet-medium model Signed-off-by: MahnoorAsghar <masghar@redhat.com>
7868818 to
cece950
Compare
|
/test e2e-metal-ipi-bm |
|
@MahnoorAsghar: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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. |
No description provided.