addressable containers cannot resolve non-FQDN in maas

[Dimiter Naydenov]

In 1.23 the addressable containers created by juju (both LXC and KVM) have a modified /etc/resolv.conf (as seen inside the container's rootfs) which contains any "nameserver" directives, but does NOT contain a default "search" domain. This breaks charms deployed in addressable containers in MAAS (esp. in restrictive networks). It was discovered while testing 1.23.0 proposed release in UOSCI.

[Dimiter Naydenov (dimitern)]

Fix is being tested in the environment in question and once confirmed will be proposed for merging.

[Ryan Beisner (1chb1n)]

Example:

The bare metal fully qualified host name is myserver.mydomain.

With all other things being sound with regards to forward and reverse name resolution, dns and dhcp, we found that the search mydomain bit was not propagated to resolv.conf within lxc containers on the same host.

Juju tried and failed to resolve the host as simply myserver because of this missing search option in the lxc container's resolv.conf.

This appears to affect 1.23.0. We've not observed that issue when using 1.22.0.

[Dimiter Naydenov (dimitern)]

Fix for 1.23 proposed with https://github.com/juju/juju/pull/2090

[Ryan Beisner (1chb1n)]

Testing with fresh binaries with dimitern's fix:
https://github.com/dimitern/juju/commit/0354deadfdb92c74337d5891c9430d84f0a10194

[Ryan Beisner (1chb1n)]

That appears to have resolved the resolv.conf search entry issue. But now I think we are seeing a separate issue, where an lxc container isn't reachable except from the machine which is hosting that lxc container.

ubuntu@1ea-trusty032743:~/tools/openstack-charm-testing⟫ nc -w 2 10.245.168.64 22
1 ubuntu@1ea-trusty032743:~/tools/openstack-charm-testing⟫ juju ssh 1 "nc -w 2 10.245.168.64 22"
Warning: Permanently added '10.245.168.18' (ECDSA) to the list of known hosts.
Warning: Permanently added '10.245.168.19' (ECDSA) to the list of known hosts.
SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
Connection to 10.245.168.19 closed.

[Dimiter Naydenov (dimitern)]

I can confirm I was able to ping the containers both from inside the environment and outside (as well as other charms on the same host) so it's not a routing problem. It might be a MTU issue.

[Dimiter Naydenov (dimitern)]

Ryan, since you verified the original issue is solved, can you please file a bug about this separate issue with neutron-api and provide more details what you've observed and diagnosed?

[Ryan Beisner (1chb1n)]

Yes, kicked of a new deploy to reproduce. Will file and link a separate bug. Thank you!

[Ryan Beisner (1chb1n)]

FYI, that other suspected issue was not successfully reproduced, no bug to reference.