[2.5] get-curtin-config doesn't reflect the actual machine's configuration
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MAAS |
Invalid
|
Critical
|
Unassigned |
Bug Description
I had logged into my maas with:
maas login admin http://
And whenever I run:
maas admin machine get-curtin-config <system-id>
The result I get is URLs with 'localhost' instead of the actual config to be given to the machine:
apt:
preserve_
primary:
- arches:
- default
uri: http://
proxy: http://
security:
- arches:
- default
uri: http://
sources:
test_3:
source: deb http://
cloudconfig:
maas-
content: "#cloud-
\ metadata_url: 'http://
\ token_secret: hVW4T8Q84QCPPNC
path: /etc/cloud/
maas-datasource:
content: 'datasource_list: [ MAAS ]'
path: /etc/cloud/
maas-reporting:
MAAS should either tell the user that this configuration if what the machine would likely get depending on which IP address they reach, or MAAS should return the one the machine actually got.
Changed in maas: | |
importance: | Undecided → Critical |
status: | New → Triaged |
milestone: | none → 2.5.0rc1 |
description: | updated |
Changed in maas: | |
milestone: | 2.5.0rc1 → 2.5.0 |
Changed in maas: | |
milestone: | 2.5.0 → 2.5.x |
I think this occurs because the IP address is decided dynamically, based on how the request was made.
For example, imagine the following setup:
Management network: 172.16.0.0/24
Intranet: 10.0.0.0/24
Rack controller has IPs:
172.16.0.2
10.0.0.2
Imagine a machine PXE boots from the 172 network. The curtin config will then instruct it to contact 172.16.0.2. If the same system is reconfigured in the BIOS and begins to boot from the 10 network, the configuration will reflect that and tell the machine to contact 10.0.0.2.
We /could/ check for subnet links on the boot_interface and try to make a better guess at the time the API call is made. It wouldn't be perfect but could allow for easier troubleshooting.