rndc.key in designate-bind's application units is different from rndc.key in designate's units

[Jorge Rodríguez]

Hello,

In a charmed Openstack Yoga with the following designate/designate-bind applications:

-1 designate application (3 units) (14.0.1, yoga/stable, revision 88)
-1 designate-bind application A (2 units) (9.16.1, yoga/stable, revision 69)
-1 designate-bind application B (2 units) (9.16.1, yoga/stable, revision 69)
-1 designate-bind application C (2 units) (9.16.1, yoga/stable, revision 69)

the /etc/designate/rndc.key file from the designate application matches the /etc/bind/rndc.key file from the designate-bind application A.
However, the /etc/bind/rndc.key files for designate-bind applications B and C are different.

This fact leads to the following error in designate logs when creating a zone in the B or C space:

===========================================================================================================================
Exit code: 1
Stdout: ''
Stderr: 'rndc: connection to remote host closed\nThis may indicate that\n* the remote server is using an older version of the command protocol,\n* this host is not authorized to connect,\n* the clocks are not synchronized,\n* the key signing algorithm is incorrect, or\n* the key is invalid.\n': designate.exceptions.Backend: Unexpected error while running command.
2022-10-20 09:40:54.100 297 INFO designate.worker.tasks.zone [req-ed73fb03-b55b-4a44-910e-1f3beec983f7 - - - - -] Failed to UPDATE zone_name=HIDDEN. zone_id=5f297216-3f33-4347-b1a3-2989297f61e1 on target=<PoolTarget id:'f1958c28-c632-477b-8fe7-57a55a9d03f6' type:'bind9' pool_id:'794ccc2c-d751-44fe-b57f-8894c9f5c842'> on attempt=10 Error=Unexpected error while running command.
Command: sudo designate-rootwrap /etc/designate/rootwrap.conf rndc -s 10.11.12.13 -p 953 -k /etc/designate/rndc.key showzone HIDDEN
=============================================================================================================================

Steps to reproduce it:

juju deploy -n 3 designate
juju deploy mysql
juju deploy rabbitmq-server
juju deploy keystone
juju deploy memcached
juju add-relation designate memcached
juju add-relation designate mysql
juju add-relation designate rabbitmq-server
juju add-relation designate keystone

juju deploy -n 2 designate-bind designate-bind-A
juju add-relation designate designate-bind-A
juju deploy -n 2 designate-bind designate-bind-B
juju add-relation designate designate-bind-B
juju deploy -n 2 designate-bind designate-bind-C
juju add-relation designate designate-bind-C

juju run --app designate -- "ls -l /etc/designate/rndc.key && cat /etc/designate/rndc.key"
juju run --app designate-bind-A -- "ls -l /etc/bind/rndc.key && cat /etc/bind/rndc.key"
juju run --app designate-bind-B -- "ls -l /etc/bind/rndc.key && cat /etc/bind/rndc.key"
juju run --app designate-bind-C -- "ls -l /etc/bind/rndc.key && cat /etc/bind/rndc.key"

The workaround to this issue is to manually set the contents of /etc/designate/rndc.key in /etc/bind/rndc.key of the designate-bind applications B and C units. However, I'd like to know if this situation can be handled by the designate-bind charm itself by updating the rndc.key file accordingly.

Thank you,

Jorge R.

[Walid Moghrabi (walid-fdj)]

I'd like to add that just changing the rndc.key (and not the rndc.key charm's template) is not enough since it will be overriden by juju.

[David Negreira (dnegreira)]

Hi,

The fix has been merged upstream https://review.opendev.org/c/openstack/charm-designate/+/897554

Pending now the backports to focal/yoga.