[RFE] use network's dns_domain to generate dns_assignment

[yong sheng gong]

Problem:
currently, the port's dns_assignment is generated by combining the dns_name and conf.dns_domain
even if the dns_domain of port's network is given.

expectation:

generate the dns_assignment according to the dns_domain of port's network, which will scope the dnsname by
network instead of each neutron deployment.

[Carl Baldwin (carl-baldwin)]

Essentially, this request is to override the dns domain used my dnsmasq on a network with the dns_domain attribute on the network. This changes the behavior without changing the API which could be a surprise to some. I actually thought this was what we were going to do when first introducing the dns_domain attribute to the network. So, from my perspective, it is a bug. But, apparently this was the designed behavior.

I kind of think we should do this but we might be trapped by backwards compatibility.

[Boden R (boden)]

[1][2] seem related if not encompassing.

[1] https://bugs.launchpad.net/neutron/+bug/1512666
[2] https://review.openstack.org/#/c/247027/

[Akihiro Motoki (amotoki)]

The request sounds reasonable. DNS integration for ports are internal ports, so it makes sense that a DHCP service inform an instance of network's dns_name instead of dns_name from neutron.conf.

Regarding API behavior change, I am not sure which is better we need some info to indicate API behavior change or not.
This hits me a question that an initial version of some feature can be considered as a stable API.

[Armando Migliaccio (armando-migliaccio)]

Status update:

http://eavesdrop.openstack.org/meetings/neutron_drivers/2016/neutron_drivers.2016-05-19-22.01.log.html#l-251

[Armando Migliaccio (armando-migliaccio)]

Needs more thought.

[Carl Baldwin (carl-baldwin)]

Putting it on the back burner by setting to Confirmed.

[Jonathan Mills (jonmills-t)]

I am still seeing this in Pike. Any chance we can get some traction on this?

[James Page (james-page)]

This commit:

  https://opendev.org/openstack/neutron/commit/137a6d61053

has somewhat complicated this problem as the dns_domain set on the network now might get used in some parts of the configuration of the dnsmasq instance for a network.

This becomes inconsistent as a dns_assignment record is generated for a port centrally using the CONF.dns_domain which is then used by the DHCP agent to generate the hosts file for dnsmasq, however the "--domain" parameter for the dnsmasq instance will be set to the dns_domain of the network.

Net result is that forward/reverse lookups are not mirrored:

root@bionic-045546-2:~# host 192.168.21.222
222.21.168.192.in-addr.arpa domain name pointer bionic-045546-2.jamespage.internal.
root@bionic-045546-2:~# host bionic-045546-2
bionic-045546-2.designate.local has address 192.168.21.222

and the search path for an instance is set to the dns_domain of the network which won't match the dns_assigned records written to the hosts file for dnsmasq.

[James Page (james-page)]

Comments in #9 related to the fix in bug 1774710 which I think has broken the contract on the dns_domain of a network being used for external DNS integration only.

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

Bug closed due to lack of activity, please feel free to reopen if needed.