MAAS enlistment fails when region is behind a NAT
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MAAS |
Fix Released
|
High
|
Unassigned | ||
2.3 |
Fix Released
|
High
|
Unassigned |
Bug Description
MaaS 2.3 no longer allows explicit configuration of the metadata_url used for cloud-init in bootstrapping nodes. When running regiond in Kubernetes behind a NodePort, the response to get_enlist_preseed is not accessible and not even reasonable.
Introduced by: https:/
Region routing info:
root@maas-
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
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1
link/ipip 0.0.0.0 brd 0.0.0.0
4: eth0@if54: <BROADCAST,
link/ether 36:dd:0a:ce:cf:70 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.97.166.173/32 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::34dd:
valid_lft forever preferred_lft forever
root@maas-
default via 169.254.1.1 dev eth0
169.254.1.1 dev eth0 scope link
root@maas-
172.24.1.1 via 169.254.1.1 dev eth0 src 10.97.166.173
cache
root@maas-
database_host: postgresql.
database_name: maasdb
database_pass: ########
database_user: maas
maas_url: http://
Response to get_enlist_preseed
ubuntu@
* Trying 172.24.1.100...
* Connected to 172.24.1.100 (172.24.1.100) port 31900 (#0)
> GET /MAAS/metadata/
> Host: 172.24.1.100:31900
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Fri, 12 Jan 2018 15:48:09 GMT
< Server: TwistedWeb/16.0.0
< X-Maas-Api-Hash: 42eb95deab0d98e
< Vary: Authorization,
< Content-Type: text/plain
< X-Frame-Options: SAMEORIGIN
< Transfer-Encoding: chunked
<
#cloud-config
datasource:
MAAS:
timeout : 50
max_wait : 120
# there are no default values for metadata_url or oauth credentials
# If no credentials are present, non-authed attempts will be made.
metadata_url: http://[::1]:31900/
output: {all: '| tee -a /var/log/
* Connection #0 to host 172.24.1.100 left intact
ubuntu@
172.24.1.100 dev pxe1-if src 172.24.1.1
cache
root@maas-
Desired=
| Status=
|/ Err?=(none)
||/ Name Version Architecture Description
+++-===
un maas <none> <none> (no description available)
ii maas-cli 2.3.0-6434-
ii maas-common 2.3.0-6434-
ii maas-dns 2.3.0-6434-
ii maas-proxy 2.3.0-6434-
ii maas-region-api 2.3.0-6434-
ii maas-region-
un maas-region-
un python-django-maas <none> <none> (no description available)
un python-maas-client <none> <none> (no description available)
ii python3-django-maas 2.3.0-6434-
ii python3-maas-client 2.3.0-6434-
ii python3-
Related branches
- Mike Pontillo (community): Approve
-
Diff: 182 lines (+85/-13)3 files modifiedsrc/maasserver/utils/__init__.py (+26/-0)
src/maasserver/utils/tests/test_utils.py (+58/-2)
src/metadataserver/api.py (+1/-11)
- MAAS Lander: Needs Fixing
- Newell Jensen (community): Approve
-
Diff: 182 lines (+85/-13)3 files modifiedsrc/maasserver/utils/__init__.py (+26/-0)
src/maasserver/utils/tests/test_utils.py (+58/-2)
src/metadataserver/api.py (+1/-11)
Changed in maas: | |
status: | New → Incomplete |
Changed in maas: | |
status: | Incomplete → Triaged |
importance: | Undecided → High |
milestone: | none → 2.3.x |
milestone: | 2.3.x → 2.4.0alpha1 |
Changed in maas: | |
status: | Triaged → Fix Committed |
Changed in maas: | |
status: | Fix Committed → Fix Released |
Hi Scott,
IIRC, enlistment would always use the IP address of rackd.conf maas_url field. If this one was set to localhost, MAAS would use the IP of maas_url on regiond.conf. This typically means both region and rack are in the same machine.
The bugfix you referenced, should fix situations which rackd.conf is set as localhost but we know that the machine pxe booted from an IP, and instead of blindly giving the IP of maas_url on reiond.conf, we give the right IP address of the region controller. That said, if rackd.conf has a proper maas_url, it will use that instead.
Now, if you hit the metadata directly with curl it may not give you the information you are looking for. So, to better debut this, can you also attach:
1. Rackd.conf
2. A console log when the machine is pxe booting of MAAS (which would give the kernel parameters) or the kernel log of the ephemeral environment which should also contain the Params.