Activity log for bug #1995975

Date Who What changed Old value New value Message
2022-11-08 17:17:12 Jorge Rodríguez bug added bug
2022-11-08 17:18:11 Jorge Rodríguez bug added subscriber Przemyslaw Hausman
2022-11-08 17:28:22 Jorge Rodríguez description Hello, A UA customer has 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. 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.