Comment 8 for bug 1698443

I have one environment where the same situation is reproducible even on 2.1.2 or 2.1.3.

I will try 2.2.1 and see if it works with 2.2.1 once I am able to VPN into it.

The provisioner logs with v.2.1.2 from a machine log are as follows:

2017-06-22 22:29:07 INFO juju.provisioner provisioner_task.go:406 found machine pending provisioning id:0/lxd/0, details:0/lxd/0
2017-06-22 22:29:07 INFO juju.provisioner provisioner_task.go:249 provisioner-harvest-mode is set to destroyed; unknown instances not stopped []
2017-06-22 22:31:29 INFO juju.network bridge.go:70 bridgescript command=/usr/bin/python2 - --interfaces-to-bridge="enp4s0f0 enp4s0f0.2730" --activate --bridge-prefix=br- --reconfigure-delay=0 /etc/network/interfaces <<'EOF'
<script-redacted>
EOF
2017-06-22 22:31:34 INFO juju.network bridge.go:75 bridgescript result=0, timeout=false
2017-06-22 22:31:35 WARNING juju.provisioner provisioner_task.go:739 failed to start instance (unable to find host bridge for space(s) "public-space" for container "0/lxd/0"), retrying in 10s (3 more attempts)

It complains about the lack of a bridge related to the public space although enp4s0f0.2730 interface with the respective bridge is present on a node and vlan 2730 is associated with the public-space.

---

If it still does not work for me there, I will take a look at the postgres db for MAAS and try to find out what's the reason for it: juju itself does not store provider-specific state more than needed at a given moment so IDs might be messed up in MAAS as I have changed vlan <-> space associations before on this installation. Those are my unconfirmed assumptions anyway.