Comment 0 for bug 1933303

I have a LXD container which hosts a nested LXD deployed by a charm. A such the nested LXD creates a network bridge called amsbr0 to serve nested containers. The bridge has 192.168.100.1 assigned as it's IP address and serves addresses via DHCP to nested containers from the 192.168.100.1/24 subnet. This looks as follows in the LXD running on the host:

$ lxc ls
+---------------+---------+------------------------+------+-----------+-----------+----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | LOCATION |
+---------------+---------+------------------------+------+-----------+-----------+----------+
| juju-5ae9e7-0 | RUNNING | 172.2.0.107 (eth0) | | CONTAINER | 0 | lxd0 |
+---------------+---------+------------------------+------+-----------+-----------+----------+
| juju-cef40f-0 | RUNNING | 172.2.0.88 (eth0) | | CONTAINER | 0 | lxd0 |
+---------------+---------+------------------------+------+-----------+-----------+----------+
| juju-cef40f-1 | RUNNING | 172.2.0.154 (eth0) | | CONTAINER | 0 | lxd0 |
+---------------+---------+------------------------+------+-----------+-----------+----------+
| juju-cef40f-2 | RUNNING | 192.168.100.1 (amsbr0) | | CONTAINER | 0 | lxd0 |
| | | 172.2.0.15 (eth0) | | | | |
+---------------+---------+------------------------+------+-----------+-----------+----------+

The LXD container hosting the nested LXD is juju-cef40f-2 and the other containers can be ignored here.

Asking the lxd/0 unit which is deployed into the juju-cef40f-2 container on the host gives an incorrect address for the units private-address

$ juju run -u lxd/0 -- unit-get private-address
192.168.100.1

The expected private address is 172.2.0.15 rather than 192.168.100.1 which is not accessible from outside of the container.

The problem seems to rely in the logic Juju has to determine the private-address. Looking at the relevant code in Juju shows that it only ignores bridge devices from the LXD container status which are named lxdbr0 or lxcbr0 (see https://github.com/juju/juju/blob/develop/container/lxd/container.go#L235) which is breaking things here. Instead of hardcoding the possible bridge names I think Juju should look at the network state reported by the container/vm and compare it against the container configuration and only consider network devices listed there. That should safely tell us which network devices the container uses for incoming/outgoing traffic vs those it just uses on the inside.