Comment 21 for bug 1525280

Right - this (I think) was my observation in comment #16.

So, even if the device is in /etc/network/interfaces /etc/resolv.conf is
still borked.

On 19 December 2015 at 19:07, Cheryl Jennings <<email address hidden>
> wrote:

> I think the root of the problem that's being seen in CI (where
> containers can't resolve node0.maas), is that we are manually specifying
> the network config (rather than using dhcp), but we don't manually
> specify the dns information.
>
> I've attached the two cloud-config.txt files, one from a 1.25.0 env, and
> one from 1.25.2 env. We specify a manual config for eth0 in 1.25.2, but
> don't include dns information.
>
> For the 1.25.2 case, I added dns-nameserver and dns-domain into
> /etc/network/interfaces and did an ifdown eth0 && ifup eth0, and was
> then able to resolve node0.maas. /etc/resolv.conf also had the correct
> information. Here's the modified /e/n/i:
>
> root@juju-machine-0-lxc-0:~# cat /etc/network/interfaces
>
> # loopback interface
> auto lo
> iface lo inet loopback
>
> # interface "eth0"
> auto eth0
> iface eth0 inet manual
> pre-up ip address add 192.168.100.152/32 dev eth0 &> /dev/null || true
> up ip route replace 192.168.100.1 dev eth0
> up ip route replace default via 192.168.100.1
> down ip route del default via 192.168.100.1 &> /dev/null || true
> down ip route del 192.168.100.1 dev eth0 &> /dev/null || true
> post-down ip address del 192.168.100.152/32 dev eth0 &> /dev/null ||
> true
> dns-nameserver 192.168.100.200
> dns-domain maas
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1525280
>
> Title:
> 1.25.1 with maas 1.8: devices dns allocation uses non-unique hostname
>
> Status in juju-core:
> Triaged
> Status in juju-core 1.25 series:
> Fix Committed
>
> Bug description:
> Starting with juju 1.25.1, juju will by default use MAAS devices for
> container IPs. When making the device ip reservation, juju passes
> along the container hostname. Unfortunately that container name is far
> from unique: it obeys the form juju-machine-N-lxc-M. That means all
> subsequent containers, from other environments on the same MAAS
> server, that get the same juju-machine-N-lxc-M hostname will resolve
> to an IP that is not their own.
>
> Example:
> a) User 1:
> bootstrap, status:
> environment: beretstack
> machines:
> "0":
> agent-state: started
> agent-version: 1.25.1
> dns-name: tesla.beretstack
> instance-id:
> /MAAS/api/1.0/nodes/node-1742ff26-4b4a-11e4-ad24-a0b3cce4ecca/
> series: trusty
> hardware: arch=amd64 cpu-cores=4 mem=16384M
> state-server-member-status: has-vote
> services: {}
>
> juju deploy ubuntu --to lxc:0
> $ juju deploy ubuntu --to lxc:0
> Added charm "cs:trusty/ubuntu-5" to the environment.
>
> maas log:
> Dec 11 08:41:29 virtue maas.api: [INFO] juju-machine-0-lxc-0: Added new
> device
> Dec 11 08:41:30 virtue maas.api: [INFO] juju-machine-0-lxc-0: Sticky IP
> address(es) allocated: 10.1.102.145
> Dec 11 08:41:30 virtue maas.dns: [INFO] Generating new DNS zone file for
> beretstack
> Dec 11 08:41:33 virtue maas.dns: [INFO] Generating new DNS zone file for
> 1.10.in-addr.arpa
>
> maas DNS:
> # grep -r juju-machine /etc/bind
> /etc/bind/maas/zone.1.10.in-addr.arpa:145.102.1.10.in-addr.arpa. IN PTR
> juju-machine-0-lxc-0.beretstack.
> /etc/bind/maas/zone.beretstack:juju-machine-0-lxc-0 IN A 10.1.102.145
>
> on ubuntu/0 at this point in time, we can see that the IP of
> $(hostname -f) resolves to itself:
>
> ubuntu@juju-machine-0-lxc-0:~$ ip addr show dev eth0
> 9: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UP group default qlen 1000
> link/ether 00:16:3e:c2:82:7a brd ff:ff:ff:ff:ff:ff
> inet 10.1.102.145/16 brd 10.1.255.255 scope global eth0
> valid_lft forever preferred_lft forever
> inet6 fe80::216:3eff:fec2:827a/64 scope link tentative dadfailed
> valid_lft forever preferred_lft forever
>
> hostname -f:
> $ hostname -f
> juju-machine-0-lxc-0.beretstack
>
> Which resolves back to itself as expected:
> ubuntu@juju-machine-0-lxc-0:~$ host juju-machine-0-lxc-0.beretstack
> juju-machine-0-lxc-0.beretstack has address 10.1.102.145
>
> b) Now User 2 comes along and does the same thing:
> after juju deploy ubuntu --to lxc:0
>
> You can see that the IP of $(hostname -f) resolves back to the ubuntu/0
> unit that belongs to User 1:
> ubuntu@juju-machine-0-lxc-0:~$ ip addr
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> group default
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 9: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UP group default qlen 1000
> link/ether 00:16:3e:c2:70:f2 brd ff:ff:ff:ff:ff:ff
> inet 10.1.80.164/16 brd 10.1.255.255 scope global eth0
> valid_lft forever preferred_lft forever
> inet6 fe80::216:3eff:fec2:70f2/64 scope link
> valid_lft forever preferred_lft forever
>
> ubuntu@juju-machine-0-lxc-0:~$ hostname -f
> juju-machine-0-lxc-0.beretstack
>
> ubuntu@juju-machine-0-lxc-0:~$ host juju-machine-0-lxc-0.beretstack
> juju-machine-0-lxc-0.beretstack has address 10.1.102.145
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1525280/+subscriptions
>

--
Andrew McDermott <email address hidden>
Juju Core Sapphire team <http://juju.ubuntu.com>