Comment 9 for bug 1698443

I'm pretty sure that is "bridge names too long" which is a different bug,
also fixed (I believe) in 2.2.

https://bugs.launchpad.net/juju/+bug/1672327

The issue is that br-enp4s0f0.2730 was the default naming scheme in 2.1
which ends up being over the 15 character maximum for device names. Which
means we would *try* to create a bridge, but then fail, and then there
would be no bridge to create the container. That should have been fixed for
2.2.beta4.

I'm pretty sure 2.2 doesn't suffer from "bridge names too long", but might
instead be failing because of this bug. (Which should be fixed in 2.2.1).

On Fri, Jun 23, 2017 at 4:36 PM, Dmitrii Shcherbakov <
<email address hidden>> wrote:

> 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.
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1698443
>
> Title:
> Juju-2.2 does not create interfaces in an LXD for all spaces
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1698443/+subscriptions
>