juju deploy --to lxd:X on manually provisioned host will always use lxdbr0
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Incomplete
|
Low
|
Unassigned | ||
Ubuntu on IBM z Systems |
Triaged
|
High
|
Unassigned |
Bug Description
This bug appears to be related to https:/
Juju 2.0.2
Ubuntu 16.04
arch s390x
Summary: I can't use a bridge other than lxdbr0 (and any config changes I make to lxdbr0 are ignored) when I attempt to deploy a charm to an lxd container on a manually provisioned machine.
Detail:
In this scenario I have manually bootstrapped an s390x environment, but assume this would apply to any architecture. Additional s390x hosts are then manually provisioned (add-machine ssh:ubuntu@ip)
Once the juju agents are reported as 'started', deploy the ubuntu charm to lxd containers on those hosts:
juju deploy ubuntu --to lxd:0 (and subsequently add-unit --to lxd:?)
The LXD containers then acquire IP addresses from lxd-bridge process / dnsmasq on the host, but I want these containers to acquire IP addresses from a DHCP server on the network (i.e. I want them to use a different bridge interface).
Regardless of the changes I make to the profile, either via "lxc profile edit default" or by modifying /etc/default/
modify /etc/default/
USE_LXD_
LXD_BRIDGE=
directly modify and show profile:
sudo lxc profile show default
name: default
config: {}
description: Default LXD profile
devices:
eth0:
name: eth0
nictype: bridged
parent: notlxdbr0
type: nic
lxd-bridge stopped, lxd restarted
juju add-unit -n1 ubuntu --to lxd:13
| juju-e059b4-
sudo lxc info juju-e059b4-
Name: juju-e059b4-
Remote: unix:/var/
Architecture: s390x
Created: 2017/01/10 05:32 UTC
Status: Running
Type: persistent
Profiles: default
Pid: 27453
Ips:
eth0: inet6 fe80::216:
lo: inet 127.0.0.1
lo: inet6 ::1
ubuntu@
bridge name bridge id STP enabled interfaces
eth0 8000.000000000000 no
lxdbr0 8000.fe9da9f9e7b4 no vethEYO2WE
vethRIXQUA
notlxdbr0 8000.020000c15bcc no encc000.2893
ubuntu@
manually deployed containers use the correct bridge:
sudo lxc launch ubuntu
The local image 'ubuntu' couldn't be found, trying 'ubuntu:' instead.
Creating thorough-coyote
Starting thorough-coyote
| thorough-coyote | RUNNING | 10.13.3.234 (eth0) | | PERSISTENT | 0 |
$ sudo lxc info thorough-coyote
Name: thorough-coyote
Remote: unix:/var/
Architecture: s390x
Created: 2017/01/10 05:41 UTC
Status: Running
Type: persistent
Profiles: default
Pid: 28839
Ips:
eth0: inet 10.13.3.234 vethUO1MBH
eth0: inet6 fe80::216:
lo: inet 127.0.0.1
lo: inet6 ::1
$ brctl show
bridge name bridge id STP enabled interfaces
eth0 8000.000000000000 no
lxdbr0 8000.fe9da9f9e7b4 no vethEYO2WE
vethRIXQUA
notlxdbr0 8000.020000c15bcc no encc000.2893
vethUO1MBH
If I delete lxdbr0 and attempt to deploy another container with juju:
sudo ifconfig lxdbr0 down
sudo brctl delbr lxdbr0
juju add-unit -n1 ubuntu --to lxd:13
It fails, agent state down, and the following appears in the logs:
...
https:/
...
I have also attempted to manually pre-configure lxdbr0, but /etc/default/
summary: |
- lxd on manually provisioned host will always use lxdbr0 + juju deploy --to lxd:X on manually provisioned host will always use + lxdbr0 |
tags: | added: uosci |
tags: | added: s390x |
Changed in ubuntu-z-systems: | |
status: | New → Confirmed |
tags: | added: multi-lpar |
Changed in ubuntu-z-systems: | |
importance: | Undecided → Critical |
Changed in juju: | |
status: | New → Triaged |
importance: | Undecided → High |
milestone: | none → 2.1.0 |
Changed in ubuntu-z-systems: | |
status: | Confirmed → Triaged |
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:/