Atm horizon haproxy firewall rules obfuscate any other rule defined via
the tripleo.haproxy.firewall_rules key.
Things broke with https://review.opendev.org/#/c/625600/. The reason
that was pushed is that in composable roles, when splitting off horizon
away from where haproxy runs, we would not have the proper iptables rules
on the haproxy role. This was due to the fact that we had
the following code: service_config_settings: haproxy: tripleo.horizon.firewall_rules: '127 horizon': dport: - 80 - 443
The above code never worked as explained in
3f8ce6fd96bc4f28a052b4c87a19b4b152734091 and so we fixed it by setting
the proper tripleo.haproxy.firewall_rules key. The issue is that rules
for haproxy should just never have been set at all via
service_config_settings keys in the first place. As demonstrated with
this bug, the merging of hiera dictionaries will mess us up and we'll
end up overwriting other keys. Haproxy stats access has this:
outputs:
role_data: description: Role data for the HAproxy role.
value: service_name: haproxy monitoring_subscription: {get_param: MonitoringSubscriptionHaproxy} config_settings: map_merge:
- tripleo.haproxy.firewall_rules: '107 haproxy stats': dport: 1993
And since hiera will return the horizon settings for
tripleo.haproxy.firewall_rules which won't be deep merged with the
firewall rules from haproxy stats and so rule '107 haproxy stats' will
never be present.
Rules for haproxy need to happen in puppet-tripleo/manifests/haproxy*.
Normally they do, the exception is horizon which uses a specialized
horizon_endpoint.pp manifest which does not trigger these rules.
Let's create the firewall rules in haproxy/horizon_endpoint.pp like we
do for all other endpoints.
Tested and correctly got:
[root@controller-0 ~]# iptables -nvL |grep hor
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 80 state NEW /* 100 horizon_haproxy ipv4 */
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 state NEW /* 100 horizon_haproxy_ssl ipv4 */
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 80,443 state NEW /* 126 horizon ipv4 */
Change-Id: I1325171ef60d7a7e3b57373082fcdb5487be939b
Related-Bug: #1829338
(cherry picked from commit 6c2e164adaa0bf0bbc38a3d69e16db105a5519aa)
Reviewed: https:/ /review. opendev. org/661339 /git.openstack. org/cgit/ openstack/ puppet- tripleo/ commit/ ?id=f58d8af343c 24a709fdfb73553 4e2dc6b4209338
Committed: https:/
Submitter: Zuul
Branch: stable/stein
commit f58d8af343c24a7 09fdfb735534e2d c6b4209338
Author: Michele Baldessari <email address hidden>
Date: Thu May 16 09:12:50 2019 +0200
Fix horizon firewall rules in composable roles
Atm horizon haproxy firewall rules obfuscate any other rule defined via haproxy. firewall_ rules key.
the tripleo.
Things broke with https:/ /review. opendev. org/#/c/ 625600/. The reason
service_ config_ settings:
haproxy:
tripleo. horizon. firewall_ rules:
'127 horizon':
dport:
- 80
- 443
that was pushed is that in composable roles, when splitting off horizon
away from where haproxy runs, we would not have the proper iptables rules
on the haproxy role. This was due to the fact that we had
the following code:
The above code never worked as explained in c4f28a052b4c87a 19b4b152734091 and so we fixed it by setting haproxy. firewall_ rules key. The issue is that rules config_ settings keys in the first place. As demonstrated with
description: Role data for the HAproxy role.
service_ name: haproxy
monitoring_ subscription: {get_param: MonitoringSubsc riptionHaproxy}
config_ settings:
map_ merge: haproxy. firewall_ rules:
'107 haproxy stats':
dport: 1993
3f8ce6fd96b
the proper tripleo.
for haproxy should just never have been set at all via
service_
this bug, the merging of hiera dictionaries will mess us up and we'll
end up overwriting other keys. Haproxy stats access has this:
outputs:
role_data:
value:
- tripleo.
And since hiera will return the horizon settings for haproxy. firewall_ rules which won't be deep merged with the
tripleo.
firewall rules from haproxy stats and so rule '107 haproxy stats' will
never be present.
Rules for haproxy need to happen in puppet- tripleo/ manifests/ haproxy* . endpoint. pp manifest which does not trigger these rules.
Normally they do, the exception is horizon which uses a specialized
horizon_
Let's create the firewall rules in haproxy/ horizon_ endpoint. pp like we
do for all other endpoints.
Tested and correctly got: controller- 0 ~]# iptables -nvL |grep hor
[root@
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 80 state NEW /* 100 horizon_haproxy ipv4 */
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443 state NEW /* 100 horizon_haproxy_ssl ipv4 */
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 80,443 state NEW /* 126 horizon ipv4 */
Change-Id: I1325171ef60d7a 7e3b57373082fcd b5487be939b bbc38a3d69e16db 105a5519aa)
Related-Bug: #1829338
(cherry picked from commit 6c2e164adaa0bf0