6220fe1bd3
The reason for this is that under deploy_tasks they won't be run during an update (until the converge command is run). This is problematic because in a composable HA being updated the haproxy firewall rules might disappear due to other tasks cleaning the rules up and they won't be recreated until converge. The problem is that that the temporary containers will run during the minor update and try to access the db which is now effectively firewalled off. Historically this was at step 2, because haproxy was configured during that step. Nothing should prevent us from creating the rules before and that is what we do for the non-haproxy rules too anyway. While moving it we need to take out the code from ::tripleo::profile::base::haproxy and use it directly because we do not have the required 'step' variable set in host_prep_tasks and silly puppet has now way of passing a hiera value on the command line (or via other simple means) Tested as follows: 1) Deployed a fresh Train environment with this patch and correctly observed the haproxy fw rules: [root@controller-0 ~]# iptables -nvL INPUT |grep _haproxy |wc -l 27 2) Ran a minor update of controller-2, controller-1 and controller-0 (in that order) and verified that afterwards all _haproxy rules are in place *before* the converge. 3) Confirmed that in the minor update logs we do see the step where haproxy rules are enforced (previously this was not the case): $ grep 'Run puppet on the host to apply IPtables rules' update-controller-2.log TASK [Run puppet on the host to apply IPtables rules] ************************** 4) Run a full minor update + converge of a composable HA environment Closes-Bug: #1871646 Change-Id: Icba8a8292d1e2675c7da3513d00a4a0f4191747e |
||
|---|---|---|
| .. | ||
| haproxy-container-puppet.yaml | ||
| haproxy-edge-container-puppet.yaml | ||
| haproxy-internal-tls-certmonger.j2.yaml | ||
| haproxy-pacemaker-puppet.yaml | ||
| haproxy-public-tls-certmonger.yaml | ||
| haproxy-public-tls-inject.yaml | ||