race condition to write allow-notify config and service restart : refused notify from non-master

Bug #1789205 reported by Nobuto Murata on 2018-08-27

This bug report will be marked for expiration in 53 days if no further activity occurs. (find out why)

8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Designate-Bind Charm
Undecided
Unassigned

Bug Description

I saw one instance in a customer deployment that DNS notify from designate unit was refused with "refused notify from non-master".

Aug 27 07:43:10 juju-ed63ca-1-lxd-17 named[70436]: client 10.X.Y.Z#48534: received notify for zone 'admin.mydomain.example.com'
Aug 27 07:43:10 juju-ed63ca-1-lxd-17 named[70436]: zone admin.mydomain.example.com/IN: refused notify from non-master: 10.X.Y.Z#48534

The IP address 10.X.Y.Z was actually in /etc/bind/named.conf.options as:

allow-notify { 10.X.Y.ZX;10.X.Y.Z;10.X.Y.ZY; };

and "rndc reload" on designate-bind units solved the issue. So it looks like there is a race condition between writing /etc/bind/named.conf.options and restarting/reloading the service.

Will attach juju-crushdump when I can reproduce the issue in my testbed.

There has been a lot of effort to improve designate and designate-bind communication over the last release. I'm going to mark this as incomplete pending further reproduction.

Changed in charm-designate-bind:
status: New → Incomplete
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers