Comment 6 for bug 1999668

Passing runs in silo1 have the following network definitions (forward and reverse DNS works):
- public-space 10.244.8.0/24
- oam-space 10.244.40.0/21
- internal-space 192.168.33.0/25
- ceph-replica-space 192.168.35.0/26
- ceph-access-space 192.168.36.0/26
Failing runs in silo 2 have the following network definitions:
- public-space 10.244.8.0/24 => forward and reverse DNS ok
- oam-space 10.246.40.0/21 => forward and reverse DNS ok
- internal-space 192.168.33.128/25 => rev dns fail
- ceph-replica-space 192.168.35.64/26 => rev dns fail
- ceph-access-space 192.168.36.64/26 => rev dns fail

Swapping the last three spaces between silo1 and silo2 leads to swapping test outcomes: the run in silo2 passes and the one in silo1 fails. It appears that MAAS - bind interaction in updating reverse zone configuration for network prefixes larger than /24 with non-zero last octet leads to incorrect reverse DNS configuration. Presence of these networks leads to reverse DNS failures in queries that correspond to such networks.

Note that multi-node (HA) deployment in silo2 seems to suffer from unexpected pacemaker/corosync behavior that restarts PostgreSQL process periodically. This appears to be a red herring that distracted us for a while, until the tests were switched to run with a single-node MAAS setup, without HA, with same results as above.