** Changed in: charm-designate-bind Status: Confirmed => Invalid ** Summary changed:
- replacing designate units causes issues previously created zones + designate-manage pool update doesn't reflects targets master dns servers into zones. ** Description changed: + [Environment] + + Ubuntu + Ussuri + + [Description] + + If running designate-manage pool update with new targets, those targets + gets properly updated in the pool target masters list, but those aren't + reflected into the zones that belongs to this pool, therefore, the masters + associated to that zones aren't updated causing failures as the expressed + in the Further Information section. + + designate-manager pool update should offer an option to update the zones + associated to the pools with the new target masters and be able to apply + these changes into existing zones. + + For the case of the bind9 backend the current workaround is to manually + run the rndc modzone command with the new masters, but that's not suitable + for large installations with multiple zones and pools. + + + [Further information] + We have a designate/designate-bind setup. We migrated designate units to different machines, replacing 3 designate units with 3 new units. However, this caused issues with existing zones, including creating new recordsets for these zones. The zone would result in having an ERROR status and a CREATE action. Looking at the designate bind units, we see that designate is attempting to run: 'addzone $zone { type slave; masters {$new_designate_ips port 5354;}; file "slave.$zone.$hash"; };' This addzone fails due to the zone already existing. However, we found that the zone configuration (using 'rndc showzone $zone' from designate- bind unit) still had the old designate ips for its masters. There are also logs in /var/log/syslog like the following: May 20 06:27:10 juju-c27f05-15-lxd-1 named[72648]: transfer of '$zone' from $old_designate_ip#5354: failed to connect: host unreachable We were able to resolve this issue by modifying the zone config on all designate-bind units: juju run -a designate-bind -- rndc modzone $zone '{ type slave; file "slave.$zone.$hash"; masters { $new_designate_ip_1 port 5354; $new_designate_ip_2 port 5354; $new_designate_ip_3 port 5354; }; };' After modifying the zone, the recordset creations completed and resolved almost immediately. Would this be something the charm could do in an automated way when masters are removed/replaced, or is there a better way of fixing the zone configurations? For these designate migrations, we will have to enumerate over every zone to fix their configurations. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1879798 Title: designate-manage pool update doesn't reflects targets master dns servers into zones. To manage notifications about this bug go to: https://bugs.launchpad.net/charm-designate/+bug/1879798/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs