puppetlabs/razor-server — pull request #212 by lutter (2014-05-20 05:34:48+00:00)
Title: Significantly change how we identify nodes to reduce the risk of data loss

This is an alternative to PR 142, which is less intrusive and also addresses https://tickets.puppetlabs.com/browse/RAZOR-218. Since this is a fairly intrusive change in a core part of Razor, I'd highly appreciate all reviews.
--------------------------------------------------------------------------------------------------------------------------------------
We used to assume that calls to /svc/boot would completely identify nodes;
this had two important shortcomings:

* it was not possible for users to identify nodes based on facts (e.g.,
HDD UUID's) so that even changing the mainboard of a machine will not
lead to assuming a node is new; changing a mainboard is fairly common
in large operations, and it is generally hard to coordinate that with
manually changing the Razor database

* if the HW info that iPXE sent us did not give us the complete picture
of the hardware, e.g. by using undionly.kpxe, which will only send us
the MAC address on which the machine did its DHCP, we could
accidentally identify the same physical node as two separate nodes in
the database (if DHCP happened sometimes on one NIC and sometimes on
another NIC) with the attendant risk of data loss

With this change, Razor makes another attempt at identifying the hardware
during requests to /svc/checkin at which point we have the full facts about
the node. If a previous request to /svc/boot misidentified the node and
created a new entry in the database, /svc/checkin will now detect that and
clean up the database by merging the newly created node (which will not
have facts yet as these are not set by /svc/boot) into the existing node.

Most of the work of deduplication is done in Node.register.

Users can now guide deduplication by having Node.register match on certain
facts, controlled by the facts.match_on configuration setting, which by
default is empty. Users must ensure that the facts they use to identify
nodes are truly distinct across their machines, otherwise physically
distinct nodes might get coalesced in the database.