fix(k8s): fail fast in /info when the API server does not answer - #119
Conversation
The /info probe inherited the 60 s K8S_HTTP_TIMEOUT. AppAPI waits 5 s for /info in its daemon checks, so an unreachable API server surfaced as "Cannot reach HaRP" after a 5 s hang on every admin page load. The probe now has its own 3 s timeout and /info reports why the cluster is unreachable in a new "error" field. Signed-off-by: Oleksandr Piskun <oleksandr2088@icloud.com>
|
Warning Review limit reachedNext included review available in 18 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe change adds a three-second Kubernetes API probe timeout. The new Priority: ⬇️ Low — Defer this Kubernetes /info probe change because it is a focused timeout and error-reporting improvement without elevated product-impact evidence. Merge Risk: 🔵 Low · up to The /info endpoint now performs a short Kubernetes probe and returns failure details. Repeated checks may create unnecessary connections, and HTTP 403 messages may direct operators toward token troubleshooting instead of RBAC permissions; both should be corrected before merge. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Advanced
Run ID: a2f84e58-7ec1-47c1-97c4-12d40308e2ba
📒 Files selected for processing (1)
haproxy_agent.py
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.
Address review feedback on the probe added in the previous commit: - read the response body inside the request context, like `_k8s_request` already does, and append it (truncated to 200 chars) to the error. The Kubernetes `Status.message` names the actual problem, e.g. `forbidden: User "..." cannot get path "/api"`. Leaving the body unread also made aiohttp drop the pooled connection whenever the body did not arrive with the headers, which is exactly the degraded API server this probe targets. - report HTTP 401 and 403 separately: 401 is authentication, so the bearer token hint is right; 403 is authorization, where a valid token is denied by RBAC and the token hint sends operators the wrong way. - add the missing docstring to `get_info`. Signed-off-by: Oleksandr Piskun <oleksandr2088@icloud.com>
2 participants
The
/infoprobe of the Kubernetes API server inheritedK8S_HTTP_TIMEOUT(60 s). AppAPI waits 5 s for/infoin its daemon checks, so an unreachable API server surfaced as "Cannot reach HaRP: cURL error 28" after a 5 s hang on every admin page load and Check connection.The probe now has its own 3 s timeout (has to stay below AppAPI's 5 s) and
/inforeports why the cluster is unreachable in a newerrorfield, e.g.HTTP 401with a token hint, TLS error, connection refused, or timeout.reachablekeeps its meaning, so current AppAPI releases are unaffected.Tested against a kind cluster with the API server paused:
/info60 s -> 3 s, AppAPI daemon check 5.3 s with the wrong message -> 3.3 s with the right one; ExApp deploy/disable/enable/unregister through the patched HaRP unchanged.