juju deployed lxd falls back to lxdbr0 bridge when binding is specified

[Brad Marshall]

While trying to deploy a new service to an older stack I'm running into problems with the interfaces being used by lxd. I've tried deploying the service both via juju-deployer and juju deploy, and appear to be hitting the same problem.

When deploying via juju deploy, I used a command line like:

  $ juju deploy mycharm --to lxd:x --series xenial --bind space-0

When deploying via juju-deployer I added the following to the service definition:

  bindings:
      "": space-0

In both cases the LXD came up with the eth0 bound to lxdbr0, as per:

$ sudo lxc config device show juju-204ac4-3-lxd-7
eth0:
  name: eth0
  nictype: bridged
  parent: lxdbr0
  type: nic
root:
  path: /
  type: disk

This gives it an address in 10.0.0.0/24 IP range, which isn't very useful as nothing else can talk to it.

I believe what should be happening is the parent of the eth0 bridge should be br-enp6s0, which is the interface on the metal server that has the appropriate address on it.

Please let me know if you need any further information.

OS Version:
$ lsb_release -rd
Description: Ubuntu 16.04.2 LTS
Release: 16.04

Juju version:
Model Controller Cloud/Region Version
model-name maas-controller cloud-name 2.0.3

$ dpkg-query -W maas
maas 2.1.3+bzr5573-0ubuntu1~16.04.1

[Anastasia (anastasia-macmood)]

It looks like you have experienced this failure in an early version of Juju 2x. I wonder if you are experiencing the same issue with later Juju 2?

I'll re-target to "juju" project. "juju-core" is reserved for Juju 1x

[John A Meinel (jameinel)]

This is a dup of a fixed bug (the part about falling back to lxdbr0). It does indicate that there is an underlying failure to create the container. (The issue was that in 2.0 if Juju failed to actually create the container in the space requested, it would fall back to just creating a container on lxdbr0 instead of just reporting the error.)
There is likely still a root-cause of why we were unable to provision the container. So I wouldn't immediately expect that Juju 2.1/2.2 will succeed in creating the container for you, but we should at least be giving you a better error as to why we couldn't do what you asked.

(It may also be possible to fix the request in 2.0 so that it will deploy, which is what you'll need to do in 2.1/2.2 but we'll at least point you towards what you need to do in newer releases.)

[John A Meinel (jameinel)]

You might be able to see what the failure in the logs is with:
 juju model-config -m controller "logging-config=<root>=DEBUG"
and then
 juju debug-log -m controller

And watch while the container is trying to be started. There should be a message about what error happened, and that we're falling back to lxdbr0.

It might even be on WARNING level, etc, but its been a while since I worked directly on this.