Comment 0 for bug 1175211

Using Networking DHCP agent, cloud-init and Nova metadata, we're seeing a situation where the VM hostname does not match the DNS name. This causes things like 'sudo' and 'hostname -f' to fail on the VM, and represents a regression from existing nova-network behavior.

An example of the problem and a potential solution are outlined below for comment.

For example:

$ nova list
+--------------------------------------+---------+--------+-----------------------------------+
| ID | Name | Status | Networks |
+--------------------------------------+---------+--------+-----------------------------------+
| 92a4075e-31a4-45e1-909d-f71ee4c55de4 | jvm44 | ACTIVE | jnet41=10.10.20.5|
+--------------------------------------+---------+--------+-----------------------------------+

On the VM:

root@jvm44:~# hostname
jvm44
root@jvm44:~# hostname -f
hostname: Temporary failure in name resolution
root@jvm44:~# sudo bash
sudo: unable to resolve host jvm44

Changing the hostname to match DNS name fixes the problem:

root@jvm44:~# hostname 10-10-20-5
root@jvm44:~# hostname -f
10-10-20-5.openstacklocal
root@jvm44:~# sudo bash
root@10-10-20-5:~#

The VM name in DNS is 10-10-20-5.openstacklocal. as seen here:

root@jvm44:~# nslookup 10.10.20.5
Server: 10.10.20.2
Address: 10.10.20.2#53
5.20.10.10.in-addr.arpa name = 10-10-20-5.openstacklocal.

While DNSaaS may be the eventual answer to this problem, there may be a simpler fix for the case where DNSaaS is not available.

A potential, minimally invasive fix for this might be:

1) modify quantum/agent/linux/dhcp.py _output_hosts_file to set the DNS name from the port name (if port name is set and if it is a valid DNS name, otherwise set from fixed IP as currently done)

2) modify nova to set the port name to match the VM name