Properly Use Network's DNS Domain in Assignment and DHCP

[Jay Jahns]

When we were trying to register an instance via agent to an external cloud backup service, the instance returned a FQDN not consistent with what its floating IP was set to, and not what the service needs to return a successful registration.

We are using Designate and OVN/ML2 on 2023.2 in a production environment.

The dns_domain value of the project network was configured with the zone that was created in Designate, thus allowing floating IP addresses to create records accordingly.

However, the dns_domain of the network is not used in dns_assignment, nor is it used as the search domain, as it uses the conf value alone.

There was an attempt made to fix the DHCP side of this:
https://bugs.launchpad.net/neutron/+bug/1774710

It was reverted in this change:
https://bugs.launchpad.net/neutron/+bug/1826419

Adjusting the ML2 extension for DNS can result in the necessary dns_assignment changes, which in-turn, update the lease in dnsmasq; however, it does not incorporate the search domain update. Functionally, this one change seems to have fixed the registration problems we were experiencing, but I can see where the search domain could also have impacts.

Other use cases include externally managed automation, such as AWX/Ansible, which may rely on the FQDN being returned back by the instance in order to function correctly.

Considering this is in the critical path for us to have functional, I believe that it merits discussion for change.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron/+/920459

[Jay Jahns (jayjahns)]

Looks like there are additional tempest tests that occur that assume the dns_domain is extracted frmo the configuration files.

In order to validation to occur, we would have to update this test to use the dns_domain of the network if present.
https://opendev.org/openstack/neutron-tempest-plugin/src/commit/1a8b36e2333d5aa58e5c4621a123e4b8e911a8a5/neutron_tempest_plugin/scenario/test_internal_dns.py#L138

[Jay Jahns (jayjahns)]

Looks like the dns portion internally is failing due to the dns_domain being different than what the config file references.

In order to fix that, there needs to be change on the ovn component, passing the dns_domain into the dhcp option domain-name.

I will add that with the test case. Additionally, the neutron-dhcp-agent may require inclusion.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/921772