designate-manage pool update doesn't reflects targets master dns servers into zones.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Designate |
Fix Released
|
Undecided
|
Jorge Niedbalski | ||
Ubuntu Cloud Archive |
Fix Released
|
Undecided
|
Unassigned | ||
Stein |
Fix Released
|
Undecided
|
Unassigned | ||
Train |
Fix Released
|
Undecided
|
Unassigned | ||
Ussuri |
Fix Released
|
Undecided
|
Unassigned | ||
Victoria |
Fix Released
|
Undecided
|
Unassigned | ||
Wallaby |
Fix Released
|
Undecided
|
Unassigned | ||
Xena |
Fix Released
|
Undecided
|
Unassigned | ||
designate (Ubuntu) |
Fix Released
|
Medium
|
Jorge Niedbalski | ||
Focal |
Fix Released
|
Medium
|
Unassigned |
Bug Description
[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/
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.
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-
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.
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.
tags: | added: scaleback |
Changed in charm-designate-bind: | |
status: | New → Confirmed |
Changed in charm-designate: | |
status: | New → Confirmed |
Changed in charm-designate: | |
assignee: | nobody → Jorge Niedbalski (niedbalski) |
Changed in charm-designate-bind: | |
assignee: | nobody → Jorge Niedbalski (niedbalski) |
Changed in charm-designate-bind: | |
status: | Confirmed → Invalid |
summary: |
- replacing designate units causes issues previously created zones + designate-manage pool update doesn't reflects targets master dns servers + into zones. |
description: | updated |
Changed in designate (Ubuntu): | |
importance: | Undecided → Medium |
Changed in designate (Ubuntu Focal): | |
importance: | Undecided → Medium |
affects: | charm-designate → designate |
Changed in designate: | |
status: | Invalid → Fix Released |
affects: | charm-designate-bind → ubuntu-translations |
no longer affects: | ubuntu-translations |
Changed in designate (Ubuntu): | |
status: | Fix Committed → Fix Released |
### Further observations ####
I am able to partially reproduce the problem.
Bundle used: http:// paste.ubuntu. com/p/myxQJnJvy n/
$ openstack zone create --email <email address hidden> example.com.
$ rndc showzone example.com.
zone "example.com" { type slave; file "slave. example. com.f3e3fdaa- 857e-4786- afef-2b4cb2d033 57"; masters { 10.5.0.10 port 5354; 10.5.0.41 port 5354; 10.5.0.31 port 5354; }; };
$ juju remove-unit designate/0 designate/1 designate/2 --force
removing unit designate/0
removing unit designate/1
removing unit designate/2
root@juju- 54f98f- 1879798- 4:/home/ ubuntu# ack master /var/log/syslog 1879798- 4 named[1505]: received control channel command 'addzone example.com { type slave; masters { 10.5.0.10 port 5354; 10.5.0.41 port 5354; 10.5.0.31 port 5354;}; file "slave. example. com.f3e3fdaa- 857e-4786- afef-2b4cb2d033 57"; };' 1879798- 4 named[6653]: zone example.com/IN: refresh: timeout retrying without EDNS master 10.5.0.10#5354 (source 0.0.0.0#0) 1879798- 4 named[6653]: zone example.com/IN: refresh: retry limit for master 10.5.0.10#5354 exceeded (source 0.0.0.0#0) 1879798- 4 named[6653]: zone example.com/IN: refresh: retry limit for master 10.5.0.41#5354 exceeded (source 0.0.0.0#0) 1879798- 4 named[6653]: zone example.com/IN: refresh: retry limit for master 10.5.0.31#5354 exceeded (source 0.0.0.0#0)
May 27 19:21:20 juju-54f98f-
May 27 19:55:32 juju-54f98f-
May 27 19:55:47 juju-54f98f-
May 27 19:56:05 juju-54f98f-
May 27 19:56:23 juju-54f98f-
$ juju add-unit -n 3 designate
root@juju- 54f98f- 1879798- 4:/home/ ubuntu# ack addzone /var/log/syslog 1879798- 4 named[1505]: received control channel command 'addzone example.com { type slave; masters { 10.5.0.10 port 5354; 10.5.0.41 port 5354; 10.5.0.31 port 5354;}; file "slave. example. com.f3e3fdaa- 857e-4786- afef-2b4cb2d033 57"; };' 1879798- 4 named[1505]: added zone example.com in view _default via addzone
May 27 19:21:20 juju-54f98f-
May 27 19:21:20 juju-54f98f-
---
(Continues).