(follow-up from T346385)
The problem
In cloudservices hosts, /etc/designate/pools.yaml contains several configuration values for OpenStack Designate. These values dictate what Designate writes to the pdns MariaDB database, running on the same cloudservices hosts.
After adding the new "private" vlan, cloudservices are using different source addresses for local vs. remote updates, which is not possible to describe correctly in pools.yaml.
This means that when a cloudservices host is added/reimaged, the database must be edited manually to set the right values (details documented here).
More details
In eqiad1, we have the following setup:
| Host | Allowed Masters |
|---|---|
| cloudservices1005 | 185.15.56.162 (itself), 172.20.1.5 (cloudservices1006) |
| cloudservices1006 | 185.15.56.163 (itself), 172.20.2.4 (cloudservices1005) |
The destination addresses for updates will be 185.15.56.162 (ns0 / 1005) and 185.15.56.163 (ns1 / 1006). As those addresses are in the 185.15.56.0/24 network, the hosts will use their cloud-private interface to get there, hence the 172.20.x addressing rather than 10.x.
Ideally we could just have 185.15.56.162 and 185.15.56.163 on both, covering the local and remote system in either case. But instead we need a different pair of IPs on each, as the systems are using different source addresses for local vs. remote updates. We could include all 4 IPs on both, but that doesn't seem to work because pdns then expects to see updates coming from both IPs and complains that "I'm not getting updates from xxx.xxx.xxx.xxxx".