add-machine ssh:user@$IP fails if $IP is associated with lxdbr0
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Expired
|
High
|
Unassigned | ||
Ubuntu on IBM z Systems |
Triaged
|
High
|
Unassigned |
Bug Description
Juju 2.0.2
Ubuntu 16.04
arch s390x
bootstrapped with manual provider (controller is s390x)
When add-machine is executed against a host via IP, e.g.
juju add-machine ssh:ubuntu@
If the ip specified is associated with a bridge interface named lxdbr0, the machine state will be stuck in pending state
1 pending 10.13.3.10 manual:10.13.3.10 xenial
2017-01-10 04:42:47 DEBUG juju.worker.
2017-01-10 04:42:47 DEBUG juju.worker.
2017-01-10 04:42:47 DEBUG juju.worker.
2017-01-10 04:42:47 ERROR juju.worker.
2017-01-10 04:42:50 DEBUG juju.worker.
full log: http://
If the interface is renamed (to, e.g. "notlxdbr0") and the old bridge is removed (brctl delbr lxdbr0) and the same add-machine command is executed, the agent will start:
2 started 10.13.3.10 manual:10.13.3.10 xenial
affects: | juju (Ubuntu) → juju |
tags: | added: s390x uosci |
Changed in ubuntu-z-systems: | |
status: | New → Confirmed |
tags: | added: multi-lpar |
tags: | added: network |
Changed in juju: | |
status: | New → Triaged |
importance: | Undecided → High |
milestone: | none → 2.1.0 |
Changed in ubuntu-z-systems: | |
status: | Confirmed → Triaged |
importance: | Undecided → High |
tags: | added: openstack-ibm |
The following related bug is really the root cause here. If it didn't exist, we wouldn't have to try to munge the bridges ahead of Juju:
"manual provider lxc/lxd units are behind NAT, fail by default" /bugs.launchpad .net/juju/ +bug/1614364
https:/