missing DNS forwarder config

[Johannes Spanier]

should add a statement dnsmasq_dns_servers = <some-server> to /etc/neutron/dhcp_agent.ini in this step of the installation guide. Otherwise DNS will not work in the demo-instance created in Chapter 14 because dnsmasq will not know hot to handle the request in the demo-net. ping -c openstack.org will fail without the proper forwader.

-----------------------------------
Built: 2015-03-16T07:51:43 00:00
git SHA: 19f8c69ecb6542d34695c50b422f5ed11294ebdc
URL: http://docs.openstack.org/juno/install-guide/install/apt/content/neutron-network-node.html
source File: file:/home/jenkins/workspace/openstack-manuals-tox-doc-publishdocs/doc/install-guide/section_neutron-network-node.xml
xml:id: neutron-network-node

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/171088

[Prathamesh Deshpande (prathameshd)]

Hello,

I have proposed a fix for the missing dns-servers configuration parameter in the installation guide.

I am not quite sure about the general norm with the Openstack community, but while creating initial networks and launching instances, I follow this:

neutron net-create ext-net --shared --router:external True --provider:physical_network external --provider:network_type flat

neutron subnet-create ext-net --name ext-subnet --allocation-pool start=10.1.1.235,end=10.1.1.240 --disable-dhcp --gateway 10.1.1.254 10.1.1.0/24 --dns-nameservers list=true 8.8.8.8 8.8.4.4

neutron net-create demo-net

neutron subnet-create demo-net --name demo-subnet --gateway 192.168.1.1 192.168.1.0/24 --dns-nameservers list=true 8.8.8.8 8.8.4.4

Then, when I launch the instances, they are able to ping openstack.org(communicate to the internet).

P.S. This is the first bug I am working upon, so please bare with me for any delay in proposing changes, still learning the Gerrit workflow :)

Thanks and regards,
Prathamesh Deshpande

[Johannes Spanier (josp)]

Thanks Prathamesh. This seems to be a much more flexible solution to the bug. It will be easy to follow and to adapt to own experiments.

[Matt Kassawara (ionosphere80)]

I can't validate this bug. Without specifying DNS servers during network creation, the DHCP server passes its IP address for name resolution. In my test environments, instances can resolve hostnames using this IP address.

[Prathamesh Deshpande (prathameshd)]

Hello Matthew,

Please check http://paste.openstack.org/show/203826/. Here, I have listed down all the steps from network creation till booting instance. Please note, in my environment the parameter 'dnsmasq_dns_servers' in '/etc/neutron/dhcp_agent.ini' is commented.

Please elaborate your setup. Are you saying tenant's DHCP server?

[Sam Yaple (s8m)]

Hey guys. I finally got a few moments to track this issue down. The link below shows that the dnsmasq server will _not_ resolve dns requests. It is hard-coded.

https://github.com/openstack/neutron/blob/2015.1.0/neutron/agent/linux/dhcp.py#L304

Here is the output of a command line launched by neutron. "--no-resolv" will prevent it from reading /etc/resolv.conf on the host.

dnsmasq --no-hosts --no-resolv --strict-order --bind-interfaces --interface=tap7044be39-f2 --except-interface=lo --pid-file=/var/lib/neutron/dhcp/69869abe-f8b3-44f4-be93-542dfa3e29f9/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/69869abe-f8b3-44f4-be93-542dfa3e29f9/host --addn-hosts=/var/lib/neutron/dhcp/69869abe-f8b3-44f4-be93-542dfa3e29f9/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/69869abe-f8b3-44f4-be93-542dfa3e29f9/opts --leasefile-ro --dhcp-authoritative --dhcp-range=set:tag0,10.0.0.0,static,86400s --dhcp-lease-max=1024 --conf-file= --domain=openstacklocal

This is not a new issue, see these links:

https://ask.openstack.org/en/question/5042/quantum-dnsmasq-and-resolvconf/
http://www.gossamer-threads.com/lists/openstack/operators/34548

Matt, I don't know why you are unable to reproduce this, I suspect a configuration option or a different dns responder on the system. But with the "--no-resolv" in addition to not specifiying a seperate resolv.conf to read from, I don't see how the dnsmasq process launched by neutron on your system could be responding to these requests.

I would like to see the proposed patch merged.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Matthew Kassawara (<email address hidden>) on branch: master
Review: https://review.openstack.org/171088
Reason: Abandoning to clean up queue. You can restore if necessary.

[Matt Kassawara (ionosphere80)]

Does not affect Liberty. Need patch for Juno and Kilo.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/kilo
Review: https://review.openstack.org/244352

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/244352
Committed: https://git.openstack.org/cgit/openstack/openstack-manuals/commit/?id=4d0960a89227c428aa408fa6e5ccd1f3f73745f1
Submitter: Jenkins
Branch: stable/kilo

commit 4d0960a89227c428aa408fa6e5ccd1f3f73745f1
Author: Matthew Kassawara <email address hidden>
Date: Wed Nov 11 15:57:39 2015 -0700

    [install] Explictly configure DNS resolver

    In Kilo, explicitly configure DNS resolver during tenant
    subnet creation so instances can resolve domain names.

    Also applies to Juno.

    Change-Id: I27f4859009abb8ff2a788ce90bf370da1a7e0999
    Closes-Bug: #1439369
    backport: juno