Cannot claim sticky IP address for a device with parent unless observed IPs exist for the parent

Bug #1514486 reported by Dimiter Naydenov on 2015-11-09
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
Critical
Unassigned

Bug Description

Using maas 1.9.0~beta2+bzr4456-0ubuntu1~trusty1.

I've discovered that after adding a device via the CLI, e.g.:

$ maas hw-root devices new hostname=device-11 mac_addresses=00:16:3e:de:fa:e0 parent=node-14eb8374-83bb-11e5-b6d7-0015f231d37e
(created OK, e.g. deviceID=node-728f2a40-86f3-11e5-bcee-0015f231d37e)

and then trying to claim a sticky ip address for it:
$ maas hw-root device claim-sticky-ip-address node-728f2a40-86f3-11e5-bcee-0015f231d37e
(returned no error, but the "ip_addresses" list in the response was still empty).

Looking at the log in /var/log/maas/maas.log I see the following error:
Nov 9 16:31:51 maas-hw maas.interface: [ERROR] Tried to allocate an IP to interface <name=eth0, type=physical, mac=00:1
6:3e:de:fa:e0>, but its cluster interface is not known.
Nov 9 16:31:51 maas-hw maas.api: [INFO] device-11: Sticky IP address(es) allocated:
(no IP or anything).

However, since I was able to do claim a sticky IP for another device on another node, I started digging into the maasserver source, and I suspect the reason for that error is because I'm not passing a requested_address and MAAS tries to find an available one but ONLY among the "discovered_ips" (AIUI observed DHCP requests for the same subnet and node (the parent)).

I can readily reproduce this by dropping the dhcpd.leases file, deleting all records maasserver_staticipaddresses where ip is null (but first delete the attached records from maasserver_interface_ip_addresses due to ref integrity checks), and running dpkg-reconfigure maas-dhcp. This removes all "discovered" IPs (as seen from the subnet details page in the web UI, as well as in the DB). From that point any attempt to claim a sticky IP for a device fails with that error. It works if I specify an available IP as requested_address though, just to clarify.

In case anybody else hits this issue, here's how I managed to fix it:
1. first, make sure all your nodes have static IP assigned (not auto or DHCP) for their primary (PXE) interface (it might make a difference where there are more than one NIC).
2. $ rm -f /var/lib/maas/dhcpd.leases
3. $ dpkg-reconfigure maas-dhcp
4. recommission all nodes
5. after it's done, you should see at least 1 "observed" IP per node in the managed subnet's UI details page (needs to be refreshed manually sometimes), and creating devices + claim-sticky-ip-address for the device, on any of the nodes should work.

Related branches

Changed in maas:
importance: Undecided → Critical
milestone: none → 1.9.0
status: New → Triaged
Mike Pontillo (mpontillo) wrote :

Just so you know, I think step (4) alone would have been enough. That is, regardless of DHCP, recommissioning a node under 1.9 should cause it to create "discovered" (aka "observed") addresses.

Do I assume correctly that this MAAS setup had been upgraded from 1.8? Upgraded nodes will not have "observed" IP addresses yet.

Dimiter Naydenov (dimitern) wrote :

Good to know recommissioning should fix it. I just wanted to clean up stale DHCP leases and old observed IPs as much as possible.

Yes, it was upgraded from 1.8.

Blake Rouse (blake-rouse) wrote :

Mike,

I don't think a discovered IP address should be a requirement if the parent node has an interface at least connected to a managed cluster interface no matter the mode (aka. AUTO, STATIC, OR DHCP).

Mike Pontillo (mpontillo) wrote :

Thanks all.

I ageee; if we can determine the cluster interface, we can determine the subnet.

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

Other bug subscribers