[2.5] get-curtin-config doesn't reflect the actual machine's configuration

Bug #1798676 reported by Andres Rodriguez
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
Invalid
Critical
Unassigned

Bug Description

I had logged into my maas with:

maas login admin http://localhost:5240/MAAS/ <oauth>

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_sources_list: false
  primary:
  - arches:
    - default
    uri: http://us.archive.ubuntu.com/ubuntu
  proxy: http://192.168.1.73:8000/
  security:
  - arches:
    - default
    uri: http://us.archive.ubuntu.com/ubuntu
  sources:
    test_3:
      source: deb http://uk.archive.ubuntu.com/ubuntu $RELEASE main
cloudconfig:
  maas-cloud-config:
    content: "#cloud-config\ndatasource:\n MAAS: {consumer_key: rWwxwDPKsucHXBPuU8,\
      \ metadata_url: 'http://localhost:5240/MAAS/metadata/',\n token_key: 4yk6bMvU4VW58sRff9,\
      \ token_secret: hVW4T8Q84QCPPNCwgf6MhAcCcqErfGvV}\n"
    path: /etc/cloud/cloud.cfg.d/90_maas_cloud_config.cfg
  maas-datasource:
    content: 'datasource_list: [ MAAS ]'
    path: /etc/cloud/cloud.cfg.d/90_maas_datasource.cfg
  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
Revision history for this message
Mike Pontillo (mpontillo) wrote :

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.

Changed in maas:
milestone: 2.5.0 → 2.5.x
Revision history for this message
Adam Collard (adam-collard) wrote :

This bug has not seen any activity in the last 6 months, so it is being automatically closed.

If you are still experiencing this issue, please feel free to re-open.

MAAS Team

Changed in maas:
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.