dnsmasq doesn't write new dns_name entry

[Kenneth Cummings]

Hello everyone,

we are seeing some problems with the dns_name entry on newly created ports/instances. This problem doesn't happen on every tenant, actuaqlly it's happening only in one tenant.

After creating an instance over Horizon or CLI the newly created port gets the entry dns_name with the name of the instance:

root@mgmt1:~# neutron port-show 66ddad0f-d2a4-4278-9f59-f5beb28b7165
+-----------------------+------------------------------------------------------------------------------------+
| Field | Value |
+-----------------------+------------------------------------------------------------------------------------+
| admin_state_up | True |
| allowed_address_pairs | |
| binding:host_id | node1 |
| binding:profile | {} |
| binding:vif_details | {"port_filter": true} |
| binding:vif_type | bridge |
| binding:vnic_type | normal |
| created_at | 2017-03-23T13:41:43 |
| description | |
| device_id | 2f2f2fbe-6730-4d3f-bcf7-039a610459eb |
| device_owner | compute:nova |
| dns_assignment | {"hostname": "test", "ip_address": "172.16.0.22", "fqdn": "test.ssolocal."} |
| dns_name | test |
| extra_dhcp_opts | |
| fixed_ips | {"subnet_id": "f1299032-48cd-439e-b452-a3bd41995194", "ip_address": "172.16.0.22"} |
| id | 66ddad0f-d2a4-4278-9f59-f5beb28b7165 |
| mac_address | fa:16:3e:b3:e9:66 |
| name | |
| network_id | f883223c-ca24-4cd5-b1a3-97e9a928aaad |
| port_security_enabled | True |
| security_groups | d2005738-f142-4a09-a2e3-4e78bd2ebb86 |
| | f6aa9984-6468-446a-a778-e552dd8ec2f7 |
| status | ACTIVE |
| tenant_id | 174b1a7ca42b4e108140b792bac638b1 |
| updated_at | 2017-03-23T13:41:51 |
+-----------------------+------------------------------------------------------------------------------------+

This entry looks perfect as expected, but now looking into the addn_hosts/host files of the dnsmasq configuration for the DHCP/DNS Namespace the entry is not set correctly with the defined hostname:

root@neutron2:/var/lib/neutron/dhcp/f883223c-ca24-4cd5-b1a3-97e9a928aaad# fgrep 22 *
addn_hosts:172.16.0.22 host-172-16-0-22.openstacklocal host-172-16-0-22
host:fa:16:3e:b3:e9:66,host-172-16-0-22.openstacklocal,172.16.0.22

If we now make a port-update on the port only declaring the same dns_name again it is passed to the dnsmasq configuration and the instance is reachable within the network with it's hostname:

root@mgmt1:~# neutron port-update 66ddad0f-d2a4-4278-9f59-f5beb28b7165 --dns_name test
Updated port: 66ddad0f-d2a4-4278-9f59-f5beb28b7165

root@neutron2:/var/lib/neutron/dhcp/f883223c-ca24-4cd5-b1a3-97e9a928aaad# fgrep 22 *
addn_hosts:172.16.0.22 test.ssolocal. test
host:fa:16:3e:b3:e9:66,test.ssolocal.,172.16.0.22

As described the problem only seems to happen within one tenant (or at least we haven't seen it yet anywhere else)
Does anybody know why dnsmasq/neutron is behaving like this?

Kind regards,
Kenneth Cummings

[Kenneth Cummings (kenneth-cummings)]

Had forgotten to mention, we are currently on Mitaka release but already planning to upgrade to Newton.

[Miguel Lavalle (minsel)]

We have found this bug before: https://bugs.launchpad.net/neutron/+bug/1579977. We fixed in the Newton cycle here: https://review.openstack.org/#/c/313291/. Since the reported indicates that they are upgrading to Newton, they will receive the fix. I will marked this bug as "fix released".