Designate synchronisation inconsistensies with Neutron-API

Bug #1993628 reported by DUFOUR Olivier
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Designate Charm
Incomplete
Undecided
Unassigned
neutron
New
Undecided
Unassigned

Bug Description

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

Revision history for this message
Brian Haley (brian-haley) wrote :

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

Revision history for this message
Billy Olsen (billy-olsen) wrote :

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

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.