Address the dns sync issues when using native DNS feature
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
networking-ovn |
New
|
Undecided
|
Unassigned |
Bug Description
At the time of reporting this bug, the patch to use native OVN DNS feature in networking-ovn is still under review [1]
There are certain design issues with the approach the patch [1] has taken mainly due to the way OVN Northbound db is designed to store DNS information.
Below is the copy of the comments from Lucas (It is copied AS IS so that it is documented in this bug report and also to discuss the proper solution).
************
There's two points about the races here.
1st point: The race does not happen only when two ports are created with the same DNS name, it could happens between the deletion of one port and the creation of another one. Which is the same problem we have for Address Sets at the moment: https:/
So even if we enforce dns_name to be unique via the Neutron API, the race could still happen between the time it's deleted from OVNDB and the time of creation in NeutronDB.
2nd point: From a UX standpoint, networking-ovn should adhere to what is allowed in the Neutron API.
Otherwise, the API is not good if each backend technology behaves differently from each other.
If someone using Neutron/OVS runs:
$ openstack port create port1 --dns-name mydns --device vm1
$ openstack port create port2 --dns-name mydns --device vm2
And that's a use case, and that works, he can expect that Neutron/OVN will also work for that (it's the exactly same input).
...
We could make an argument that the use case for having the same dns_name in the API for different ports shouldn't be allowed (getting the API to have a minimum common standard) but, even then we will still hist the 1st problem due to the OVNDB design.
************