bhouse-nexthop opened a new issue, #14633: URL: https://github.com/apache/cloudstack/issues/14633
### problem When a virtual router can't replace `/etc/haproxy/haproxy.cfg`, it still reports a load balancer config change as applied. `CsLoadBalancer.process()` (`systemvm/debian/opt/cloud/bin/cs/CsLoadBalancer.py`) writes the new config to `haproxy.cfg.new`, checks it with `haproxy -c`, and then installs it with `CsHelper.copy()`. `CsHelper.copy()` catches the `IOError`, logs `Could not copy /etc/haproxy/haproxy.cfg.new to /etc/haproxy/haproxy.cfg`, and returns. The router then reloads HAProxy, which reads the old file, and the config run ends successfully. The management server therefore gets a successful answer, records the change as applied, and doesn't roll it back, while the router keeps serving the old configuration. A config that fails `haproxy -c` already makes the apply fail, so only this path is silent. ### versions 4.22 (the code is the same on main). ### The steps to reproduce the bug 1. Create a load balancer rule on an isolated network or VPC served by a virtual router. 2. On the router, make the config file unwritable, for example `chattr +i /etc/haproxy/haproxy.cfg`. 3. Change the rule, for example `updateLoadBalancerRule algorithm=leastconn`, or add a rule. 4. The API call succeeds and `listLoadBalancerRules` shows the new values. The router's `/var/log/cloud.log` has `Could not copy /etc/haproxy/haproxy.cfg.new to /etc/haproxy/haproxy.cfg`, and `/etc/haproxy/haproxy.cfg` still has the old config. ### What to do about it? Fail the apply when the new config can't be installed, the same way as when it fails `haproxy -c`, so that the management server sees the failure and rolls back. -- 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]
