github-actions[bot] commented on issue #14242: URL: https://github.com/apache/cloudstack/issues/14242#issuecomment-5833306551
## ๐ฏ Triage report The reporter's HAProxy backends behind the CloudStack Virtual Router load balancer terminate long-running requests (>50s) because the default `timeout server`/`timeout client` values (50s) and `retries 3` are hardcoded, causing HTTP 499s and duplicate retried requests. They are asking for a way to configure these HAProxy timeout/retry values (e.g. via a global setting) rather than hand-editing the VR config, which gets overwritten on redeploy/reload. ### ๐ Assessment | Dimension | Value | Reasoning | |---|---|---| | **Type** | `type:enhancement` | Requesting configurability of an existing hardcoded HAProxy setting, not a defect in current documented behavior. | | **Component** | `component:virtual-router`, `component:networking` | Issue concerns the VR's HAProxy load-balancer configuration. | | **Severity** | n/a | Not tagged as a bug; no severity assessed. | | **Labels** | type:enhancement, component:virtual-router, component:networking | See above. | | **Coding agent** | Needs more info | The ask is clear in intent, but exposing HAProxy `timeout server`/`timeout client`/`retries` as a configurable global/network setting requires a design decision (new global setting vs. per-network-offering vs. per-LB-rule) and touches VR config-generation code paths โ needs maintainer input before implementation. | ### ๐ Similar issues - https://github.com/apache/cloudstack/issues/9582 (related, closed) โ Same underlying HAProxy `timeout client`/`timeout server` (50s default) on the VR caused health-check failures after manual edits were overwritten on config reload. Related root cause (hardcoded 50s timeouts) but different symptom and already closed. <details><summary>๐ก Notes and suggestions</summary> - The report is missing the exact CloudStack version and hypervisor in use; useful to request before implementation, though the core ask (configurable HAProxy timeouts) is understandable without it. - Worth checking if a global setting already exists for LB HAProxy behavior (e.g. `network.loadbalancer.haproxy.stats.*`) that could be extended, versus introducing new settings like `haproxy.timeout.server`, `haproxy.timeout.client`, and `haproxy.retries`. - Any new setting would need corresponding changes in the VR config generator (python scripts that render `haproxy.cfg` from CloudStack config) and would need to be applied on VR (re)configuration paths, not just health-check. - Consider whether this should be a per-network-offering / per-LB-rule setting rather than a single global value, since timeout requirements vary widely by workload. </details> > Generated by [Daily Issue Triage](https://github.com/apache/cloudstack/actions/runs/36141615455) ยท sonnet50 89.8K ยท [โท](https://github.com/search?q=repo%3Aapache%2Fcloudstack+%22gh-aw-workflow-call-id%3A+apache%2Fcloudstack%2Fdaily-issue-triage%22&type=issues) > <details> <summary>Add this agentic workflows to your repo</summary> To install this agentic workflow, run ``` gh aw add githubnext/agentics/workflows/daily-issue-triage.md@d7c1dc4b72b00607a67caaffdcc216cb64379cf9 ``` </details> <!-- gh-aw-agentic-workflow: Daily Issue Triage, engine: copilot, version: 1.0.52, model: claude-sonnet-5, id: 36141615455, workflow_id: daily-issue-triage, run: https://github.com/apache/cloudstack/actions/runs/36141615455 --> <!-- gh-aw-workflow-call-id: apache/cloudstack/daily-issue-triage --> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
