DNS failure when using MAAS DNS and multiple interfaces

[Mathew Young]

When using MAAS DNS and multiple interfaces, MAAS registers different hostnames for each interface.

So on a machine (hostname: node01 with multiple VLANs eg,

eth0: 10.10.0.5/24 (vid: untagged)
  eth0.2: 10.20.0.5/24 (vid: 2)

you get 2 DNS entries

- node01.maas => 10.10.0.5
- eth0.2.node01.maas => 10.20.0.5

when using "spaces" so that you're potentially using both interfaces

the following error occurs during "live migration" and more specifically the 'cloud-compute-relation-changed' hook

/var/log/juju/unit-nova-cloud-controller-0.log:2019-06-05 03:24:09 DEBUG cloud-compute-relation-changed dns.resolver.NoNameservers: All nameservers failed to answer the query enp7s0. IN A: Server 127.0.0.53 UDP port 53 answered SERVFAIL

that results from the following code in hooks/nova-cc-utils.py:1086 (or 1094)

short = private_address.split('.')[0] (1096)

short = hn.split('.')[0] (1094)

If you need more information/logs, let me know and I'm happy to provide it

This pattern also occurs in a wide range of openstack charms due to its inclusion in the charmhelpers code base, including

charm-ceph-mon
charm-ceph-osd
charm-ceph-radosgw
charm-cinder
charm-glance
charm-keystone
charm-neutron-api
charm-neutron-gateway
charm-neutron-openvswitch
charm-nova-cloud-controller
charm-nova-compute
charm-openstack-dashboard
charm-percona-cluster
charm-rabbitmq-server

specifically:

- charmhelpers/contrib/network/ip.py:539
- charmhelpers/contrib/openstack/ssh_migrations.py:251+256

Unsure of the consequences of this, as so far I've only encountered an error with nova cloud controller

Possible fix would be to replace

fqdn.split('.')[0] with '.'.join(fqdn.split('.')[:-1])

but I can't convince myself this is the right approach either as it doesn't seem it would play nicely with complex sub domains. Why not use fqdns instead of short hostnames when you have them.

[James Page (james-page)]

Scoping bug back to potential impact area; most charms carry a copy of charmhelpers but they won't be impacted by this issue.

[Alex Kavanagh (ajkavanagh)]

This doesn't actually result in a hook failure, though, does it? i.e. it's just the charm saying it can't resolve the short name; in this case the short name is not added to the known_hosts file and thus isn't distributed for SSH migration usage by nova.

Thus, is the bug about the log report, and not actually a failure in the cloud in some way?

[Mathew Young (failsafe89)]

At this stage I can't say for sure. It's been a while since I've done a deploy. I was definitely having issue with the cloud and sporadic hook failures when I encountered this problem and have since moved to a custom patched version of the charms to address the DNS issue, but it was so long ago I can't say for sure that the patch is the actual reason for it working in the end.

I don't currently have a development environment to test this out again right now.

[Launchpad Janitor (janitor)]

[Expired for OpenStack nova-compute charm because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for OpenStack nova-cloud-controller charm because there has been no activity for 60 days.]