Juju created LXD containers with MAAS provider do not honor the default gateway on the host
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Fix Released
|
High
|
Witold Krecicki |
Bug Description
$ juju version
2.2.2-xenial-amd64
maas 2.2.2
The host has 103.X.Y.Z as the default gateway, but created LXD containers on top it have 10.10.23.254 as the default gateway instead. Therefore, created LXD containers cannot reach to hosts in other network because of the unexpected route. FWIW, 10.10.23.254 is the gateway of PXE boot network.
## Host
[curtin-
...
- bond_interfaces:
- eno1
- eno2
id: bond0
mac_address: 24:6e:96:3d:3a:e8
mtu: 1500
name: bond0
params:
bond-
bond-
bond-miimon: 100
bond-mode: 802.3ad
bond-updelay: 0
bond-
subnets:
- address: 10.10.22.110/22
dns_
type: static
type: bond
...
- id: bond0.201
mtu: 1500
name: bond0.201
subnets:
- address: 103.<snip>/26
dns_
gateway: 103.<snip>
type: static
type: vlan
vlan_id: 201
vlan_link: bond0
$ ip r | grep default
default via 103.<snip> dev br-bond0.201 onlink
## LXD container
[/var/lib/
#cloud-config
apt_mirror: ""
bootcmd:
- install -D -m 644 /dev/null '/etc/network/
- |-
printf '%s\n' '
auto lo {eth00_
iface lo inet loopback
dns-nameservers 10.10.20.21
dns-search maas
iface {eth00_
address 10.10.22.106/22
gateway 10.10.23.254
iface {eth00_
address <snip>/26
iface {eth00_
address 10.10.29.12/22
mtu 9000
' > '/etc/network/
$ ip r | grep default
default via 10.10.23.254 dev eth0 onlink
tags: | added: cdo-qa-blocker release-blocker |
tags: | added: onsite |
tags: | removed: release-blocker |
tags: |
added: cpec removed: cdo-qa-blocker onsite |
Changed in juju: | |
status: | Incomplete → Confirmed |
assignee: | nobody → Tim Penhey (thumper) |
tags: | added: cdo-qa-blocker onsite |
tags: | added: canonical-bootstack |
Changed in juju: | |
assignee: | Tim Penhey (thumper) → nobody |
importance: | Undecided → Medium |
status: | Confirmed → Triaged |
tags: | added: new-york |
tags: |
added: cpe-onsite removed: onsite |
tags: | removed: cpec |
Changed in juju: | |
milestone: | none → 2.3-beta2 |
Changed in juju: | |
milestone: | 2.3-beta2 → none |
Changed in juju: | |
status: | Triaged → In Progress |
assignee: | nobody → Witold Krecicki (wpk) |
importance: | Medium → High |
Changed in juju: | |
milestone: | none → 2.3-rc2 |
Changed in juju: | |
status: | Fix Committed → Fix Released |
This sounds like expected behavior based on configuration. We should not inherit the host machine gateway by default.
The container should only be created with access to the subnets that you have specified. And those subnets have configuration what the gateway will be to get out of that subnet. If *that* gateway doesn't have access to public networks, that may be by design. Even if you wanted access, you still need the 10.10.23.254 gateway in order to even get to the 103.* address for it to forward any farther.
It sounds like the actual fix is that you need to fix whatever gateway is at 10.10.23.254 to forward requests further on.
It may be that you need your containers to be in more than one space, if the space for their workloads cannot get public access, and you need that. You could do that with: public- space"
juju deploy application --bind private-space --constraints "spaces=