You cannot exactly "retrieve" the IP using facts, but the catalog compiler can and does receive it as a fact. The former suggests that the catalog compiler has an active role in the process, which it does not.
You have two general alternatives:
- Compute the derived value on the node
- Compute the derived value on the master
You can compute the value on the node by writing a custom fact. Its work can be simplified by relying on Facter to provide the IP to it. The result will be presented to the catalog compiler as its own, separate fact, and nothing special is required on that side to use it anywhere.
The down sides of computing the derived value as a fact include that the code for doing so is copied to all nodes, where it can potentially be examined, and if a node is compromised then in principle the value of this fact can be spoofed. Also, the custom fact would probably need to be implemented in Ruby, in case that's an issue for you.
It's not particularly harder to perform the computation in the catalog builder. You could do it as a custom function, which would be comparable in complexity to a custom fact, but I'd suggest doing it in a class, and assigning the result to a class variable of that class. How, specifically, you should implement the value computation depends on the details of that computation. For example,
class site::derived_data {
$ip_pieces = split($ipaddress, '[.]')
# This is the derived value we are computing:
$department = $ip_pieces[2] ? {
0 => 'network operations',
# ...
default => 'other'
}
}
You could then use it elsewhere like so:
class mymodule::myclass(
# parameters ...
) {
include site::derived_data
notify { $site::derived_data::department : }
}