We’d like to help you understand trusted facts and custom facts, which are powerful and often misunderstood. Trusted facts are based on the information in your certificate. Custom facts allow you to add Ruby code to generate facts about a system.
Both are pluginsync based. We recommend that you enable pluginsync to manage the distribution of facts, functions, types, and providers for your agent nodes. Otherwise, you have to manage all of those things manually.
But first, let’s talk a little bit about facts.
Hiera hierarchies provide a method of dynamically retrieving data using facts. Facts are available at the time of catalog compilation, so each node gets a customized set of paths to data. The hierarchy is always the same, but you can use facts to make dynamic decisions. For example, when you have a
datacenter fact, you can set different DNS and NTP servers for each of your datacenters in one place and then reference the appropriate key in your code. You can also make decisions on what to manage based on the fact’s value, and reference that in your code. For example, if a datacenter has Splunk, go ahead and add a Splunk forwarder, but if Splunk isn’t present in a datacenter, don’t add a Splunk forwarder.
Trusted facts is a hash that contains trusted data from the node’s certificate. You can access the data using the syntax
$trusted['fact_name']. The variable name
$trusted is reserved, so local scopes cannot reuse it.
Custom facts are written in Ruby and propagated to the agent nodes with pluginsync (if enabled.)
You can make decisions on how to name and structure custom facts for your organization’s style guide. You could name facts using a prefix. For example at Puppet, we might name facts
pup_myapptier. You could also place all facts in a container module for easier management and distribution.