Designate synchronisation inconsistensies with Neutron-API

[DUFOUR Olivier]

When setting a network to use automatically a dns-domain, some inconsistensies were observed when deleting and recreating new instances sharing the same names and associating them to the same floating IPs from before.

This has been reproduced on :
* Focal Ussuri (Neutron-api and Designate charms with Ussuri/edge branch)
* Focal Yoga (Neutron-api and Designate charms with Yoga/stable branch)

Reproducible steps :
* create a domain zone with "openstack zone create"
* configure an existing self-service with the newly created domain "openstack network set --dns-domain ..."
* create a router on the self-service network with an external gateway on provider network
* create an instance on self-service network
* create a floating ip address on provider network
* associate floating ip to instance
--> the DNS entry gets created

* delete the instance *WITH* the floating ip still attached
--> the DNS entry is deleted

* recreate a new instance with exactly the *same* name and re-use the *same* floating ip
--> the DNS entry doesn't get created
--> it doesn't seem to be related to TTL, since this makes the issue permanent even after a day of testing when TTL is set by default to 1 hour

Worse inconsistensies can be seen when, instead of deleting an instance, moving the floating ip directly to another instance
* have 2 instances vm-1 and vm-2
* attach floating ip to vm-1 "openstack server add floating ip XXX vm-1"
--> the DNS entry is created
* attach the same floating ip to vm-2 ""openstack server add floating ip XXX vm-2" (this is permitted by CLI and simply move the fIP to vm-2)
--> the DNS entry still use vm-1, vm-2 doesn't get created

When you combine these 2 issues, you can be left with either false records being kept or automatic records failing silently to be created.

Workaround :
* either always remove floating ip *before* deleting an instance
or
* remove floating ip on instance
* then re-add floating ip on instance

Eventually when deleting the floating ip to reassign it, we are gratified with this error on neutron-api unit (on Ussuri but the error is similar on Yoga) :

2022-10-19 02:24:12.497 67548 ERROR neutron.db.dns_db [req-e6d270d2-fbde-42d7-a75b-2c8a67c42fcb 2dc4151f6dba4c3e8ba8537c9c354c13 f548268d5255424591baa8783f1cf277 - 6a71047e7d7f4e01945ec58df06ae63f 6a71047e7d7f4e01945ec58df06ae63f] Error deleting Floating IP data from external DNS service. Name: 'vm-2'. Domain: 'compute.stack.vpn.'. IP addresses '192.168.21.217'. DNS service driver message 'Name vm-2.compute.stack.vpn. is duplicated in the external DNS service': neutron_lib.exceptions.dns.DuplicateRecordSet: Name vm-2.compute.stack.vpn. is duplicated in the external DNS service
2022-10-19 02:24:12.497 67548 ERROR neutron.db.dns_db Traceback (most recent call last):
2022-10-19 02:24:12.497 67548 ERROR neutron.db.dns_db File "/usr/lib/python3/dist-packages/neutron/db/dns_db.py", line 214, in _delete_floatingip_from_external_dns_service
2022-10-19 02:24:12.497 67548 ERROR neutron.db.dns_db self.dns_driver.delete_record_set(context, dns_domain, dns_name,
2022-10-19 02:24:12.497 67548 ERROR neutron.db.dns_db File "/usr/lib/python3/dist-packages/neutron/services/externaldns/drivers/designate/driver.py", line 172, in delete_record_set
2022-10-19 02:24:12.497 67548 ERROR neutron.db.dns_db ids_to_delete = self._get_ids_ips_to_delete(
2022-10-19 02:24:12.497 67548 ERROR neutron.db.dns_db File "/usr/lib/python3/dist-packages/neutron/services/externaldns/drivers/designate/driver.py", line 200, in _get_ids_ips_to_delete
2022-10-19 02:24:12.497 67548 ERROR neutron.db.dns_db raise dns_exc.DuplicateRecordSet(dns_name=name)
2022-10-19 02:24:12.497 67548 ERROR neutron.db.dns_db neutron_lib.exceptions.dns.DuplicateRecordSet: Name vm-2.compute.stack.vpn. is duplicated in the external DNS service
2022-10-19 02:24:12.497 67548 ERROR neutron.db.dns_db

[Brian Haley (brian-haley)]

Added neutron since I don't think this is specific to charms.

[Billy Olsen (billy-olsen)]

Agree that this likely isn’t a charm issue. I’ll mark invalid for now, but feel free to reopen if evidence suggests otherwise.