Bug 1582512 - networking-ovn created subnet does not offer default dns server (internal dns doesn't work then..)
Summary: networking-ovn created subnet does not offer default dns server (internal dns...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-networking-ovn
Version: 13.0 (Queens)
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: z1
: 13.0 (Queens)
Assignee: Numan Siddique
QA Contact: Eran Kuris
URL:
Whiteboard:
Depends On:
Blocks: ovndns
TreeView+ depends on / blocked
 
Reported: 2018-05-25 12:52 UTC by Miguel Angel Ajo
Modified: 2019-09-09 16:33 UTC (History)
7 users (show)

Fixed In Version: python-networking-ovn-4.0.1-0.20180420150811.c7c16d4
Doc Type: Bug Fix
Doc Text:
If the 'dns_nameservers' field is not set for a subnet, the VMs attached to the subnet have empty /etc/resolv.conf. With this fix, neutron-server gets the DNS resolver from the /etc/resolv.conf of the host from which it runs and uses it as the default dns_nameservers for the tenant VMs.
Clone Of:
Environment:
Last Closed: 2018-07-19 13:53:05 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Launchpad 1774052 None None None 2018-05-31 10:02:53 UTC
OpenStack gerrit 571006 None MERGED Add default dns_server option in DHCP_Options table 2020-10-06 22:19:07 UTC
Red Hat Product Errata RHBA-2018:2215 None None None 2018-07-19 13:53:47 UTC

Description Miguel Angel Ajo 2018-05-25 12:52:27 UTC
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

Comment 19 Eran Kuris 2018-07-09 07:55:16 UTC
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

Comment 21 errata-xmlrpc 2018-07-19 13:53:05 UTC
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


Note You need to log in before you can comment on or make changes to this bug.