Unfortunately even at the Matika release neutron networking is unable to use DNS lookup by instance name yet. The issue is that DNS entries (if DNS is configured to be used) are not created for the instance hostname, but instead are created as “host-ipaddress”; which is totally useless as if you have to know the ip-address anyway to lookup the DNS entry as “host-ipaddress”… why bother with DNS if you know the ip-address !.
This is a known irritation for openstack users and was documented as a feature enhancement (obviously still in progress) at https://specs.openstack.org/openstack/neutron-specs/specs/liberty/internal-dns-resolution.html.
The good news is the enhancement (as seen by the link URL) was identified as an issue with liberty, and a lot of the foundation work seems to be in place now for Matika. For instances created via the dashboard the port details created now correctly contain the correct details for dns_assignment and dns_name using the instance hostname which is a definate improvement.
It may even have been resolved in the “newton” release of openstack which has been available for a while now.
[root@region1server1 ~(keystone_admin)]# neutron port-list
+--------------------------------------+------+-------------------+--------------------------------------------------------------------------------------+
| id | name | mac_address | fixed_ips |
+--------------------------------------+------+-------------------+--------------------------------------------------------------------------------------+
| 12442c2f-2d2f-4126-bd76-58a4087b2e71 | | fa:16:3e:02:e3:30 | {"subnet_id": "9de25f6d-4c53-47d4-9dab-7d19f0bab113", "ip_address": "10.0.3.1"} |
| 4bb68efc-e3d9-42b7-9885-ddc78918e8b5 | | fa:16:3e:1b:be:8a | {"subnet_id": "9de25f6d-4c53-47d4-9dab-7d19f0bab113", "ip_address": "10.0.3.10"} |
| 549ab7b2-317f-4dbb-98bb-cca911dc4eef | | fa:16:3e:8f:42:b9 | {"subnet_id": "9de25f6d-4c53-47d4-9dab-7d19f0bab113", "ip_address": "10.0.3.12"} |
| 60e26ef5-ad19-4713-a7b8-82fb6885bc90 | | fa:16:3e:33:36:b1 | {"subnet_id": "2c88cd9a-623b-474b-98d1-65c5e482ae50", "ip_address": "192.168.1.235"} |
| 729c5a6c-211b-4df8-8ea7-bddf4c50abe3 | | fa:16:3e:f8:11:f1 | {"subnet_id": "2c88cd9a-623b-474b-98d1-65c5e482ae50", "ip_address": "192.168.1.236"} |
| efa70f39-66de-4c10-88b7-c7cac61ffe21 | | fa:16:3e:db:4c:11 | {"subnet_id": "2c88cd9a-623b-474b-98d1-65c5e482ae50", "ip_address": "192.168.1.234"} |
+--------------------------------------+------+-------------------+--------------------------------------------------------------------------------------+
[root@region1server1 ~(keystone_admin)]# neutron port-show 549ab7b2-317f-4dbb-98bb-cca911dc4eef
+-----------------------+----------------------------------------------------------------------------------------------------------------+
| Field | Value |
+-----------------------+----------------------------------------------------------------------------------------------------------------+
| admin_state_up | True |
| allowed_address_pairs | |
| binding:host_id | region1server1.mdickinson.dyndns.org |
| binding:profile | {} |
| binding:vif_details | {"port_filter": true, "ovs_hybrid_plug": false} |
| binding:vif_type | ovs |
| binding:vnic_type | normal |
| created_at | 2017-01-31T03:08:26 |
| description | |
| device_id | 76db9e9d-3b53-4822-bf1c-b251a1899113 |
| device_owner | compute:nova |
| dns_assignment | {"hostname": "gateway-10-0-3-0", "ip_address": "10.0.3.12", "fqdn": "gateway-10-0-3-0.mdickinson.dyndns.org."} |
| dns_name | gateway-10-0-3-0 |
| extra_dhcp_opts | |
| fixed_ips | {"subnet_id": "9de25f6d-4c53-47d4-9dab-7d19f0bab113", "ip_address": "10.0.3.12"} |
| id | 549ab7b2-317f-4dbb-98bb-cca911dc4eef |
| mac_address | fa:16:3e:8f:42:b9 |
| name | |
| network_id | 831c2bb0-cf40-49eb-a0e4-22d0c4a2bacf |
| security_groups | 83080bb5-0bb4-4c24-a723-20a4d847a319 |
| status | ACTIVE |
| tenant_id | 0b083d9b40a74894a8d841e16e888d2b |
| updated_at | 2017-01-31T03:08:31 |
+-----------------------+----------------------------------------------------------------------------------------------------------------+
[root@region1server1 ~(keystone_admin)]#
The bad news, is that as of the Matika release those details are not yet being set in the DNS resolver, for DNS lookups only the rather useless “host-ipaddr” entry is still being used.
[fedora@gateway-10-0-3-0 ~]$ ping gateway-10-0-3-0
ping: gateway-10-0-3-0: Name or service not known
[fedora@gateway-10-0-3-0 ~]$ ping gateway-10-0-3-0.mdickinson.dyndns.org
ping: gateway-10-0-3-0.mdickinson.dyndns.org: Name or service not known
[fedora@gateway-10-0-3-0 ~]$ ifconfig -a | grep "inet 10"
inet 10.0.3.12 netmask 255.255.255.0 broadcast 10.0.3.255
[fedora@gateway-10-0-3-0 ~]$ ping host-10-0-3-12
PING host-10-0-3-12.mdickinson.dyndns.org (10.0.3.12) 56(84) bytes of data.
64 bytes from host-10-0-3-12.mdickinson.dyndns.org (10.0.3.12): icmp_seq=1 ttl=64 time=1.78 ms
64 bytes from host-10-0-3-12.mdickinson.dyndns.org (10.0.3.12): icmp_seq=2 ttl=64 time=0.168 ms
64 bytes from host-10-0-3-12.mdickinson.dyndns.org (10.0.3.12): icmp_seq=3 ttl=64 time=0.178 ms
64 bytes from host-10-0-3-12.mdickinson.dyndns.org (10.0.3.12): icmp_seq=4 ttl=64 time=0.195 ms
^C
--- host-10-0-3-12.mdickinson.dyndns.org ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
While this is irritating for manually created one-off instances it is even more painfull when a group of servers are started as a stack as until the servers are built/spawned/running the provate ip-address is not known so it is not possible to even use cloud-init scripts to create a /etc/hosts file for each instance in the stack.
As the port information is now correctly configured in Matika I suppose it would be possible to automate updates to each instances /etc/hosts file periodically…
- probably in a cloud-init script chown the /etc/hosts file to the default cloud image user on each instance built
- you don’t want to assign a floating ip to every instance so you would need to run a proxy service on one of the intances to allow access to other instances on the tenant private network (or access all the instances directly from the network namespace for the tenant network (if using linux namespaces))
- periodically use neutron port commands to get all the hostname/ip-addr info to build a master “hosts” file, and push that out to every instance
- issues would be making sure only instances on the correct tenant subnet are updated that way (heat stacks would use a different keypair to manually created instances (as admin users cannot be heat_owners) so you would have to know how each instance was created to know what keypairs to use (you may need individual user keypairs if users have been creating instances [no, do not put a common root keypair in your images !]); and generally why bother as it is on the todo path and you would have to remove all those hosts files when it finally gets implemented
I don’t have any complicated stacks so can manage hosts files manually. Also the RDO project site now has the newton release available which may have already resolved this issue.
It may be fixed in newton, so…
One of my next posts will be on a quick and dirty upgrade from Matika to the “newton” release on my test nodes; all my nodes are being upgraded as I type this post. I will mention if the issue is resolved.
The most likely result will be that overwrite/upgrade in place while all openstack components are running is going to make a mess :-).
