Avoid picking the wrong IP for MAAS_URL and DEFAULT_MAAS_URL

[Christian Reis]

On multi-homed hosts MAAS seems to always pick the wrong IP address for DEFAULT_MAAS_URL. The classic case is the laptop use case which is many users' first introduction to MAAS. The IP should be one the same network as the nodes are attached to, for the obvious reason, but it's not possible to determine that before a cluster is configured.

Could we provide the user with a choice when installing MAAS? I realize a choice often reduces usability but in this case the benefit should outweigh that downside.

(I was sure I had reported this in another bug, but I can't seem to find it. Perhaps I only mentioned the issue.)

[Christian Reis (kiko)]

We also get MAAS_URL in maas_cluster.conf wrong. I think we should ask the user for both at install time, and for the installer ISO we can probably preseed the answer. I'll investigate futher.

[Christian Reis (kiko)]

(And as a simpler fix, defaulting to a wired interface might address the issue for laptop users.)

[BenLake (me-benlake)]

Chiming in as this burned 10 hours of pondering until I very clearly saw the issue watching the PXE boot show what I knew to be the incorrect MAAS IP for the cloud-config-url.

In my case, I was not using a laptop. I was using a server with a single port, two interfaces, one untagged and one tagging VLAN 100. The IP address on the VLAN 100 was no good for MAAS provisioning, but it was selected for the cloud-config-url over the untagged interface during setup. I'd like to note that the iSCSI setup used the IP address from the untagged interface.

So I second the motion to allow for entry of these IP addresses. The best of both worlds is a confirmation of discovered addresses. This let's the process be quick in terms of data entry reduction, but allows the operator to catch mistakes; rather than scratch their head for hours later. As I first stated, as soon as I saw the incorrect address in use I knew what was wrong, but I was never provided an opportunity to verify.

Cheers,

[BenLake (me-benlake)]

Expanding on my comment #3, I was using MAAS version 2.1.3+bzr5573-0ubuntu1~16.04.1 and these configuration files contained...

/etc/maas/regiond.conf
database_host: localhost
database_name: maasdb
database_pass:
database_user: maas
maas_url: http://74.117.209.194:5240/MAAS

/etc/maas/rackd.conf
cluster_uuid: 2b9694df-0b07-42b1-a92a-9e18a600117c
maas_url: http://localhost:5240/MAAS

In #maas it was mentioned that if rackd.conf contained localhost in the maas_url that the maas_url of regiond.conf would be used. I think that is extremely opaque behavior and the URL should instead be used as-is; hopefully this information is incorrect. Just in case, I chose to change localhost to an IP address just to be crystal clear about what's being used.

[Mike Pontillo (mpontillo)]

I have an approach to addressing this issue that I think will provide the most benefit with the least risk: if the rack controller does NOT specify a specific URL (that is, because it's most likely a region+rack controller connecting to the local host), rather than using the default URL from the region (which could be inaccessible to commissioning/deploying hosts), we'll perform a route lookup on the region to determine the appropriate address for the requester to contact the region. This should mean that MAAS will work out-of-the-box in most scenarios.

A longer-term fix should consider that there are actually two URLs here:

(1) The URL the rack contacts the region on
(2) The URLs that PXE booting nodes contact to get metadata from MAAS

Right now, MAAS assumes that the URL in (1) can be used for everything (which should be true for a consciously-configured high availability MAAS, but may not be true for a default configuration, which is where this usually breaks).

[Christian Reis (kiko)]

For point 2 above, after years of suffering with internal network firewalling, our field preference would be to have the nodes talk only to their rack controllers -- that would remove the concern altogether. Getting racks to talk to region is easy to justify in a security review; having nodes (which could be handling end-user workloads, etc) talk directly to region, not so much.