OSA 16.0.9 configures the Galera role (in group_vars/galera_all.yml) a whitelist for the galera monitoring on port 9200 that ends up as an xinetd service definition on the galera containers at /etc/xinetd.d/mysqlchk.
By default, that whitelist includes the "ansible_host" address of the members of the galera_all and haproxy_all groups. Unfortunately, the "ansible_host" address is potentially not the address from which the LB hosts will attempt to communicate with xinetd, e.g. where the load balancers' container management network interface is not the load balancers' default interface.
it seems to me that instead of the "ansible_host" address, OSA should instead be using the various hosts' addresses associated with their container management network interfaces (br-mgmt, by default).
The current workaround is to include the entirety of the container management network (as the exact host numbering is unknown until the creation and starting of all the containers) in the galera_monitoring_allowed_source variable in an /etc/openstack_deploy/user_*.yml file. Nevertheless, as OSA has all the information it needs to calculate the correct addresses to be whitelisted, I believe that this is a bug.
For illustration, below please find a slightly redacted copy of my openstack_user_config.yml
OSA 16.0.9 configures the Galera role (in group_vars/ galera_ all.yml) a whitelist for the galera monitoring on port 9200 that ends up as an xinetd service definition on the galera containers at /etc/xinetd. d/mysqlchk.
By default, that whitelist includes the "ansible_host" address of the members of the galera_all and haproxy_all groups. Unfortunately, the "ansible_host" address is potentially not the address from which the LB hosts will attempt to communicate with xinetd, e.g. where the load balancers' container management network interface is not the load balancers' default interface.
it seems to me that instead of the "ansible_host" address, OSA should instead be using the various hosts' addresses associated with their container management network interfaces (br-mgmt, by default).
The current workaround is to include the entirety of the container management network (as the exact host numbering is unknown until the creation and starting of all the containers) in the galera_ monitoring_ allowed_ source variable in an /etc/openstack_ deploy/ user_*. yml file. Nevertheless, as OSA has all the information it needs to calculate the correct addresses to be whitelisted, I believe that this is a bug.
For illustration, below please find a slightly redacted copy of my openstack_ user_config. yml
---
cidr_networks:
container: 10.120.241.0/24
tunnel: 10.120.242.0/24
storage: 10.120.120.0/23
used_ips: 243.1,10. 120.243. 16" 120.1,10. 120.121. 12" 6.1,10. 120.6.140" 240.1,10. 120.240. 16" 241.1,10. 120.241. 16" 242.1,10. 120.242. 16"
- "10.120.
- "10.120.
- "10.120.
- "10.120.
- "10.120.
- "10.120.
global_overrides: lb_vip_ address: openstack- internal. lab.example. com lb_vip_ address: openstack. lab.example. com bridge: "br-mgmt" networks:
container_ bridge: "br-mgmt"
container_ type: "veth"
container_ interface: "eth1"
group_ binds:
is_container_ address: true
is_ssh_ address: true
container_ bridge: "br-vxlan"
container_ type: "veth"
container_ interface: "eth10"
group_ binds: linuxbridge_ agent
container_ bridge: "br-vlan"
container_ type: "veth"
container_ interface: "eth12"
host_bind_ override: "eth12"
group_ binds: linuxbridge_ agent
container_ bridge: "br-vlan"
container_ type: "veth"
container_ interface: "eth11"
group_ binds: linuxbridge_ agent
container_ bridge: "br-storage"
container_ type: "veth"
container_ interface: "eth2"
group_ binds:
internal_
external_
management_
tunnel_bridge: "br-vxlan"
provider_
- network:
ip_from_q: "container"
type: "raw"
- all_containers
- hosts
- network:
ip_from_q: "tunnel"
type: "vxlan"
range: "1:1000"
net_name: "vxlan"
- neutron_
- network:
type: "flat"
net_name: "flat"
- neutron_
- network:
type: "vlan"
range: "1:1"
net_name: "vlan"
- neutron_
- network:
ip_from_q: "storage"
type: "raw"
- glance_api
- cinder_api
- cinder_volume
- nova_compute
- swift_proxy
shared-infra_hosts:
infra0:
ip: 10.120.240.5
infra1:
ip: 10.120.240.6
repo-infra_hosts:
infra0:
ip: 10.120.240.5
infra1:
ip: 10.120.240.6
haproxy_hosts:
balancer0:
ip: 10.120.240.11
balancer1:
ip: 10.120.240.12
log_hosts:
logging0:
ip: 10.120.240.9
logging1:
ip: 10.120.240.10
identity_hosts:
infra0:
ip: 10.120.240.5
infra1:
ip: 10.120.240.6
storage- infra_hosts:
infra0:
ip: 10.120.240.5
infra1:
ip: 10.120.240.6
image_hosts:
storage0:
ip: 10.120.240.7
storage1:
ip: 10.120.240.8
compute- infra_hosts:
infra0:
ip: 10.120.240.5
infra1:
ip: 10.120.240.6
orchestration_ hosts:
infra0:
ip: 10.120.240.5
infra1:
ip: 10.120.240.6
dashboard_hosts:
infra0:
ip: 10.120.240.5
infra1:
ip: 10.120.240.6
network_hosts:
infra0:
ip: 10.120.240.5
infra1:
ip: 10.120.240.6
compute_hosts:
aio:
ip: 10.120.240.4
storage_hosts: backends:
limit_ container_ types: cinder_volume
netapp_ storage_ family: ontap_cluster
netapp_ storage_ protocol: nfs
nfs_ shares_ config: /etc/cinder/ nfs_shares
netapp_ server_ hostname: netapp- mgmt.example. com
netapp_ server_ port: 443
netapp_ transport_ type: https
max_ over_subscripti on_ratio: 2.0
reserved_ percentage: 5
nfs_ mount_options: lookupcache=pos
netapp_ vserver: openstack
netapp_ login: cinder_api
netapp_ password: p4ssw0rd
volume_ driver: cinder. volume. drivers. netapp. common. NetAppDriver
volume_ backend_ name: netapp nfs.example. com
share: /cinderVol0 backends:
limit_ container_ types: cinder_volume
netapp_ storage_ family: ontap_cluster
netapp_ storage_ protocol: nfs
nfs_ shares_ config: /etc/cinder/ nfs_shares
netapp_ server_ hostname: netapp- mgmt.example. com
netapp_ server_ port: 443
netapp_ transport_ type: https
max_ over_subscripti on_ratio: 2.0
reserved_ percentage: 5
nfs_ mount_options: lookupcache=pos
netapp_ vserver: openstack
netapp_ login: cinder_api
netapp_ password: p4ssw0rd
volume_ driver: cinder. volume. drivers. netapp. common. NetAppDriver
volume_ backend_ name: netapp nfs.example. com
share: /cinderVol0
storage0:
ip: 10.120.240.7
container_vars:
cinder_
netapp:
shares:
- ip: netapp-
storage1:
ip: 10.120.240.8
container_vars:
cinder_
netapp:
shares:
- ip: openstack-
swift-proxy_hosts:
infra0:
ip: 10.120.240.5
infra1:
ip: 10.120.240.6
magnum-infra_hosts:
infra0:
ip: 10.120.240.5
infra1:
ip: 10.120.240.6
orchestration_ hosts:
infra0:
ip: 10.120.240.5
infra1:
ip: 10.120.240.6
swift_hosts:
storage0:
ip: 10.120.240.7
container_vars:
swift_vars:
zone: 1
storage1:
ip: 10.120.240.8
container_vars:
swift_vars:
zone: 2