Designate synchronisation inconsistensies with Neutron-API
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-
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/
2022-10-19 02:24:12.497 67548 ERROR neutron.db.dns_db self.dns_
2022-10-19 02:24:12.497 67548 ERROR neutron.db.dns_db File "/usr/lib/
2022-10-19 02:24:12.497 67548 ERROR neutron.db.dns_db ids_to_delete = self._get_
2022-10-19 02:24:12.497 67548 ERROR neutron.db.dns_db File "/usr/lib/
2022-10-19 02:24:12.497 67548 ERROR neutron.db.dns_db raise dns_exc.
2022-10-19 02:24:12.497 67548 ERROR neutron.db.dns_db neutron_
2022-10-19 02:24:12.497 67548 ERROR neutron.db.dns_db
Added neutron since I don't think this is specific to charms.