juju openstack provider --to lxd results in unit behind NAT (unreachable)

[Ryan Beisner]

Deploying to containers (lxc or lxd) using the Juju OpenStack provider results in units which are connected behind NAT on the lxc/lxd bridge. The units in containers are unreachable from outside that host instance, and are unreachable from other containers in the model.

The reproducer is simply:

juju deploy ubuntu
juju add-unit ubuntu --to lxd:0
juju add-unit ubuntu --to lxd:0

The IP addresses of 0/lxd/N will be (likely) 10.0.x.x addresses, not within the tenant's network range, and masquerading as the IP address of the hosting instance.

The hosting instance, and any other containers on the hosting instance, can successfully reach 0/lxd/N addresses via TCP/ICMP, but no other hosts can reach the container addresses.

This is essentially identical to the behavior seen in the manual provider, reference: https://bugs.launchpad.net/bugs/1614364.

For clarity, this is not related to the use of nova-lxd or the lxd charm. Advance apologies for the initial lack of accompanying evidence, and/or the potentially duplicate bug. On my next iteration, I'll gather logs, interface info, status outputs and attach here. In the mean time, please see the ultra-simple reproducer.

This needs to be re-confirmed as affecting 1.25.6 and 2.0 current beta/rc, but I do believe it affects both.

[Ryan Beisner (1chb1n)]

Confirmed with user on IRC today that this is affecting them on Juju 2.0-beta18.

[Mick Gregg (macgreagoir)]

@1chb1n Looking at the code and testing with 1.25 and 2.0, I _believe_ this is working as expected for OpenStack (and pubic clouds): lxd config on the OpenStack instance creates lxdbr0 and configures it for DHCP and NAT for any containers deployed to that instance. The work on addressable containers is not yet completed across all providers, so what you can expect from containers deployed to MAAS nodes will differ for OpenStack, for example.

Are you seeing a difference from what you've previously used?

[Ryan Beisner (1chb1n)]

Right, this is not necessarily a new issue or a regression. It is a bug to identify a long-standing and existing usability gap with the Juju OpenStack provider, and get it triaged appropriately so that it can either be made to work, or made not to work definitively.

[Trent Lloyd (lathiat)]

This bug is a duplicate of my bug here:
https://bugs.launchpad.net/bugs/1600546

It's definitely an issue, since juju never even uses this bridge subnet. lxd has long since stopped setting up such a default subnet for exactly this reason, it always interferes with something. It should be able to simply be removed.

[Richard Harding (rharding)]

Updated the duplicate bug. I see this more of the issue where Juju does not allow instructing containers to get a host network address like it does on MAAS.