agree on and fix DNS server provided by DHCP if non provided by API

[dan wendlandt]

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.

[Salvatore Orlando (salvatore-orlando)]

- 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.

[Mark McClain (markmcclain)]

Salvatore, you are correct -R and --no-resolv are equivalent, so we're covered there (I had forgotten that I had already added that option a while back).

If the subnet does not have a nameserver defined, the guest is given the address of the DHCP port running dnsmasq. The way it's setup, dnsmasq will provide local resolution or otherwise forward the request to the configured nameserver. If we default the subnet to a value, then the tenant will lose local network resolution unless the configured server knows how to provide it for the tenant's networks.

The more I've thought about it this evening, I think we should avoid making a change in this area this late in the development cycle because I think the changes have more downside than upside for this late in cycle. I am still open to changes if anyone has a use case where the current behavior is actually worse for tenants than leaving dnsmasq to forward requests.

Tangential:

Looking further down the road for Grizzly, we should take a deeper look at local name resolution. The hostnames we currently construct are of limited use and are not very meaningful They're basically a mangled ip address + default provider configured domain (defaults to fake root level .quantumlocal). Better local hostnames involve changes to both Nova and Quantum to pass names through when creating the port for the guest VM.

[dan wendlandt (danwent)]

Ok, I raised this bug because I thought that perhaps there an obvious thing that we had overlooked, but from the comments it seems like we have the core use cases covered, so it sounds like we should do anything for Folsom. I will unassign the bug from RC1 and mark it as invalid.

mark, I agree with your 'tangential' comment, though would argue it applies to global DNS as well. When creating a port, a tenant would ideally be able to setup DNS mappings for the IPs on that port, for both local and global domains.