Right now, a user with root on a managed host is able to unwittingly reconfigure foreman such that the next time that host is reprovisioned, their (bad) settings are recreated. This is because foreman draws no distinction between current host configuration as reported by facter and desired host configuration as set by the administrator. These really are very different data, and I would argue that they should be handled separately.

Examples of badness as a result of this issue:

• If the local hostname of a host changes, facter reports this change to foreman, which then creates a new host record for the host with the new name, even if this name is, say, localhost.localdomain. The original (correct) record is now reported by foreman as being out of sync.
• The host ip address is based on the facter ipaddress fact, which will change if another interface is brought up with a name that is alphabetically earlier than the primary interface. Next time the host is reprovisioned, it'll be configured with some user's VM bridge nic's IP, and will not be able to access the network.
• Fields that ought to be inherited from the hostgroup and global environments end up being populated at the host level, such that if the hostgroup value changes, the hosts in that group do not change along with it. This seems bad, too---if configuration inheritance is going to be overridden through normal use of foreman, why have it at all?

This problem has clearly already been noticed, as foreman 1.1 has an ignore_puppet_facts_for_provisioning boolean option. Unfortunately, this is only a half-solution, since it means that rather than storing the reported values and allowing the host to be reprovisioned with different (correct) values, it simply discards the current facts. Also, it only protects ip_address and mac_address---many other fields are relevant during reprovisioning.

Now, The Foreman currently draws a distinction between admin-set options and host-reported values when it comes to puppet---the former are set as params, the latter as facts. I would argue that the same should be true for reprovisioning; ie, that values (like fqdn, ip address, mac address, etc) set in foreman should stay set, and be handled similarly to parameters, and completely separately from facts. That way, facter can happily continue to do its job of reporting current host state for monitoring purposes (and for use by puppet), without opening up foreman to the risk of being accidentally misconfigured by users.

Thoughts?

In the meantime, following a suggestion from torrancew in #theforeman on freenode, I'll be disabling reporting of facts to foreman entirely from the enc script.