1.25.1 with maas 1.8: devices dns allocation uses non-unique hostname
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Fix Released
|
High
|
Andrew McDermott | ||
juju-core |
Fix Released
|
Critical
|
Dimiter Naydenov | ||
1.25 |
Fix Released
|
Critical
|
Dimiter Naydenov |
Bug Description
Starting with juju 1.25.1, juju will by default use MAAS devices for container IPs. When making the device ip reservation, juju passes along the container hostname. Unfortunately that container name is far from unique: it obeys the form juju-machine-
Example:
a) User 1:
bootstrap, status:
environment: beretstack
machines:
"0":
agent-state: started
agent-version: 1.25.1
dns-name: tesla.beretstack
instance-id: /MAAS/api/
series: trusty
hardware: arch=amd64 cpu-cores=4 mem=16384M
state-
services: {}
juju deploy ubuntu --to lxc:0
$ juju deploy ubuntu --to lxc:0
Added charm "cs:trusty/
maas log:
Dec 11 08:41:29 virtue maas.api: [INFO] juju-machine-
Dec 11 08:41:30 virtue maas.api: [INFO] juju-machine-
Dec 11 08:41:30 virtue maas.dns: [INFO] Generating new DNS zone file for beretstack
Dec 11 08:41:33 virtue maas.dns: [INFO] Generating new DNS zone file for 1.10.in-addr.arpa
maas DNS:
# grep -r juju-machine /etc/bind
/etc/bind/
/etc/bind/
on ubuntu/0 at this point in time, we can see that the IP of $(hostname -f) resolves to itself:
ubuntu@
9: eth0: <BROADCAST,
link/ether 00:16:3e:c2:82:7a brd ff:ff:ff:ff:ff:ff
inet 10.1.102.145/16 brd 10.1.255.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::216:
valid_lft forever preferred_lft forever
hostname -f:
$ hostname -f
juju-machine-
Which resolves back to itself as expected:
ubuntu@
juju-machine-
b) Now User 2 comes along and does the same thing:
after juju deploy ubuntu --to lxc:0
You can see that the IP of $(hostname -f) resolves back to the ubuntu/0 unit that belongs to User 1:
ubuntu@
1: lo: <LOOPBACK,
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
9: eth0: <BROADCAST,
link/ether 00:16:3e:c2:70:f2 brd ff:ff:ff:ff:ff:ff
inet 10.1.80.164/16 brd 10.1.255.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::216:
valid_lft forever preferred_lft forever
ubuntu@
juju-machine-
ubuntu@
juju-machine-
tags: | added: kanban-cross-team |
tags: | removed: kanban-cross-team |
Changed in juju-core: | |
status: | New → Triaged |
importance: | Undecided → Critical |
tags: | added: maas-provider network regression |
description: | updated |
Changed in juju-core: | |
milestone: | 2.0-alpha2 → 2.0-alpha1 |
Changed in juju-core: | |
milestone: | 2.0-alpha1 → 2.0-alpha2 |
Changed in juju-core: | |
status: | Triaged → In Progress |
Changed in juju-core: | |
status: | In Progress → Fix Committed |
Changed in juju-core: | |
status: | Fix Committed → Fix Released |
affects: | juju-core → juju |
Changed in juju: | |
milestone: | 2.0-alpha2 → none |
milestone: | none → 2.0-alpha2 |
Changed in juju-core: | |
assignee: | nobody → Dimiter Naydenov (dimitern) |
importance: | Undecided → Critical |
status: | New → Fix Released |
When using juju 1.25.2 (a build I got from juju's CI), the error is shown in juju debug-log:
machine-0: 2015-12-11 15:19:07 WARNING juju.apiserver. client status.go:677 error fetching public address: public no address 0-lxc-0" with MAC address "00:16: 3e:ee:e3: aa": gomaasapi: got error back from server: 400 BAD REQUEST ({"hostname": ["Node with this Hostname already exists."]}) client status.go:677 error fetching public address: public no address
machine-0: 2015-12-11 15:19:13 WARNING juju.provisioner lxc-broker.go:113 failed to prepare container "0/lxc/0" network config: failed to allocate an address for "0/lxc/0": failed creating MAAS device for container "juju-machine-
machine-0: 2015-12-11 15:19:14 WARNING juju.apiserver.
Which corresponds to the api call as seen in this apache log: 2015:09: 19:13 -0600] "POST /MAAS/api/ 1.0/devices/ ?op=new HTTP/1.1" 400 297 "-" "Go 1.1 package http"
10.1.102.146 - - [11/Dec/
Maybe juju should have failed the action in this case instead of happily continuing with the deployment?