yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #62587
[Bug 1675421] [NEW] dnsmasq doesn't write new dns_name entry
Public bug reported:
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
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1675421
Title:
dnsmasq doesn't write new dns_name entry
Status in neutron:
New
Bug description:
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
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1675421/+subscriptions
Follow ups
