HDDS-14897. Add multiple S3 gateways to the rolling-upgrade suite#10028
HDDS-14897. Add multiple S3 gateways to the rolling-upgrade suite#10028dombizita wants to merge 3 commits intoapache:HDDS-14496-zdufrom
Conversation
adoroszlai
left a comment
There was a problem hiding this comment.
Thanks @dombizita, LGTM.
| sed -i -e 's/om1,om2,om3/${new_order}/' /etc/hadoop/ozone-site.xml; \ | ||
| echo 'Replaced OM order with ${new_order} in ${c}'; \ | ||
| fi" | ||
| fi" || true |
There was a problem hiding this comment.
silently swallow genuine bash failures
This is fine. In the worst case OM client will contact follower first with the original order.
There was a problem hiding this comment.
Can we do this differerently? For example:
- Exclude haproxy containers from the loop
- Check if
/etc/hadoop/ozone-site.xmlexists in the container usingshbefore invokingbash - Reformat this to use
sh - Switch to the debian based haproxy image (30mb larger)
If we do want to use the current solution let's add a comment explaining it.
errose28
left a comment
There was a problem hiding this comment.
Thanks for adding this @dombizita. I don't have any experience configuring HA proxy but Cursor found this potential issue:
s3-haproxy.cfg uses plain balance roundrobin with no check / option httpchk and no option redispatch / retries. While a backend is stopped during rolling_restart_service, HAProxy still has a 1-in-3 chance of selecting it on each new connection, so S3 calls can fail even though two gateways are up. That works against “constant uptime” and can make the upgraded callbacks flaky.
There was a problem hiding this comment.
I think we need a wait_for_port check for s3g{1..3}. Hypothetically all the s3 gateways could be restarted faster than their individual ports are active after restart and they would all be offline for a period of time.
| sed -i -e 's/om1,om2,om3/${new_order}/' /etc/hadoop/ozone-site.xml; \ | ||
| echo 'Replaced OM order with ${new_order} in ${c}'; \ | ||
| fi" | ||
| fi" || true |
There was a problem hiding this comment.
Can we do this differerently? For example:
- Exclude haproxy containers from the loop
- Check if
/etc/hadoop/ozone-site.xmlexists in the container usingshbefore invokingbash - Reformat this to use
sh - Switch to the debian based haproxy image (30mb larger)
If we do want to use the current solution let's add a comment explaining it.
What changes were proposed in this pull request?
Use HA Proxy to load balance multiple S3 gateways. I did the necessary changes in
docker-compose.yamland adjusted the shell scripts for that. I didn't use the existings3-haproxy.yaml, as the one in common was not working out of the box with the Ozone HA setup (also found HDDS-14956). As this suite always need to have multiple S3 gateways I think it's okay to have it in thedocker-compose.yaml.One outstanding change is in the
hadoop-ozone/dist/src/main/compose/testlib.sh. Without that change I faced this error:Cursor help: "This is from reorder_om_nodes in testlib.sh. It iterates over ALL containers and runs docker exec ... bash -c "...". The HAProxy container (ha-s3g-1) uses haproxy:lts-alpine — Alpine Linux — which only has sh, not bash."
This is new, as Ozone HA suite never used S3 HAProxy setup before and if it's not Ozone HA we are not calling
reorder_om_nodes. This fix will simply skip it and as the ha proxy container doesn't needozone-site.xml, it's safe to do this. The downside is it would also silently swallow genuine bash failures. Another solution is to useshinstead ofbashWhat is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-14897
How was this patch tested?
CI with the rolling upgrade test suite: https://github.com/dombizita/ozone/actions/runs/23846523428
With commenting out (current state on HDDS-14496-zdu): https://github.com/dombizita/ozone/actions/runs/23846562903