OpenStack Designate-Bind Charm

Upgrade to 17.11 release doesn't update "private-address" relation data

Bug #1737771 reported by Tytus Kurek on 2017-12-12

This bug affects 2 people

Affects		Status	Importance	Assigned to	Milestone
	OpenStack Designate Charm	Triaged	Medium	Unassigned
	OpenStack Designate-Bind Charm	Triaged	Medium	Unassigned

Bug Description

There is juju environment with the following spaces defined:

$ juju list-spaces
Space Subnets
clo 100.86.0.0/20
oam 100.107.0.0/22
ovr 100.70.0.0/20

Designate and designate-bind charms were deployed in this environment in Sep 2017 using 17.08 release by executing the following commands:

juju deploy \
--bind "oam admin=clo internal=clo public=clo shared-db=clo dns-backend=clo" \
--config "/home/.../designate.yaml" \
--num-units 3 \
--series trusty \
--to 20/lxd/34,24/lxd/11,25/lxd/16 \
/home/.../designate \
designate

juju deploy \
--bind "oam dns-backend=clo" \
--config "/home/.../designate-bind.yaml" \
--constraints "spaces=oam,clo,ovr" \
--num-units 3 \
--series trusty \
--to 20/lxd/35,24/lxd/12,25/lxd/17 \
/home/.../designate-bind \
designate-bind

Those services have now been upgraded to 17.11 release which contains a fix for the following bug:

https://bugs.launchpad.net/charm-designate/+bug/1722794

This fix, however, only works when removing and re-adding the relation between designate and designate-bind applications. Attaching logs from all units which were upgraded on 11/12/2017 between 7 and 9 PM UTC.

Tags:

Revision history for this message

Tytus Kurek (tkurek) wrote on 2017-12-12:

logs.tar.gz Edit (98.4 KiB, application/x-tar)

Revision history for this message

Tytus Kurek (tkurek) wrote on 2017-12-12:

One more note is that after the upgrade when removing and re-adding the relation between designate and designate-bind applications the private-address of designate-bind units changes and thus, bind9 needs to be manually restarted on designate-bind units.

Revision history for this message

James Page (james-page) wrote on 2018-01-04:

I can see why this happens - the private-address is only set when the -joined hook runs on the relation - https://github.com/openstack/charm-interface-bind-rndc/blob/master/requires.py#L30

As the -joined hook is not re-executed on charm upgrade, the revised data never gets set; removing and re-adding the relation would resolve the issue as described in the original bug report.

Changed in charm-designate:
status:	New → Won't Fix
status:	Won't Fix → Confirmed
Changed in charm-designate-bind:
status:	New → Confirmed

Revision history for this message

James Page (james-page) wrote on 2018-01-04:

Note sure about #2 - the bind configuration files should be updated in the event that the IP address of the Designate DNS masters change - and bind should be restarted if that happens.

Log files from the designate-bind units would be useful.

Changed in charm-designate:
importance:	Undecided → Medium
Changed in charm-designate-bind:
importance:	Undecided → Medium
Changed in charm-designate:
status:	Confirmed → Triaged
Changed in charm-designate-bind:
status:	Confirmed → Triaged