agree on and fix DNS server provided by DHCP if non provided by API
Bug #1045537 reported by
dan wendlandt
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Invalid
|
High
|
Mark McClain |
Bug Description
A couple potential issues here:
- we have a flag that let's the provider set the default value, but that value is not visible to the tenant.
- dnsmasq also will look at /etc/resolve.conf, and use that data if needed, which is probably unexpected.
Changed in quantum: | |
importance: | Undecided → High |
assignee: | nobody → Mark McClain (markmcclain) |
milestone: | none → folsom-rc1 |
status: | New → Confirmed |
To post a comment you must log in.
- dnsmasq-dns-server flag.
Frankly, I don't see any reason for exposing this information to the tenant. If the tenant is happy with whatever the provider gives for name resolution, knowing the address of the server if probably not making a lot of difference.
- /etc/resolv.conf
We already launch dnsmasq with --no-resolv. Isn't that enough?
Also, for internal hostnames (meaning the hosts on the quantum subnet) how do we resolve the hostnames? It seems that we are currently implying that either the customer provided dns_nameserver or the provider assigned one will do that.
Correct me if I'm wrong, but the dnsmasq instance should be able to do so; if that is right, would it be possible to always assign the dnsmasq address as dns server for instance and then configure the dhcp agent to use specified dns_nameservers as upstream servers.
I realize the above is slightly off-topic, and I am not requesting you to spend any time on it. Just some food for thought.