Description of problem: This is a behavioural difference with ml2/ovs and the dhcp-agent. In the reference implementation, when a subnet is created, if no dns servers is provided the dhcp resolution will point to the dnsmasq port instance, which will resolv internal dns requests, and forward the unknown ones upstream. In the case of networking-ovn, we don't create a dhcp port for dhcp purposes. We just capture instance outgoing DNS queries, and respond to the internal ones, while the external ones are sent back to network. such implementation requires that at least one dns server has been configured via DHCP to the instance. But if during subnet creation the dns-server / dns-servers field was left unspecified, the internal dns server won't work. A temporary workaround is configuring the upstream dns server when creating the subnet: neutron subnet-update 4db68a2b-62e9-4660-9163-3e512eb47b2b --dns-nameserver 8.8.8.8 Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. create a private net and subnet openstack network create private openstack subnet create --network private private \ --subnet-range 192.168.99.0/24 2. create an instance in that network Actual results: check /etc/resolv.conf inside the instance it will be empty, Expected results: /etc/resolv.conf is at least configured with one dns server. Additional info: The possible solution to this would be, configuring on the dhcp config of nbctl the following 0) If the subnet has (a) dns-server(s) use those 1) If it does not, use a dns server provided in configuration (let's leave a sensible default like '8.8.8.8') 2) If there is no configuration, use the networking-ovn host /etc/resolv.conf nameservers
Fix verified. (undercloud) [stack@undercloud-0 ~]$ cat core_puddle_version 2018-07-03.3 rpm -qa | grep python-networking-ovn- python-networking-ovn-metadata-agent-4.0.1-0.20180420150812.c7c16d4.el7ost.noarch python-networking-ovn-4.0.1-0.20180420150812.c7c16d4.el7ost.noarch created subnet without DNS server and it gets the server name that exists in the controller created subnet with DNS server and it gets the server name the I set in the subnet. this patch still not exist in the puddle : https://review.openstack.org/#/c/554498/2
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:2215