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

Bug #1514486 reported by Dimiter Naydenov
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
Fix Released
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
Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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).

Revision history for this message
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  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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