You can setup hierarchy of YAML files in order to this. Let's start with hiera.yaml:
---
:hierarchy:
- "host/%{fqdn}"
- "domain/%{domain}"
- "env/%{::environment}"
- "ops/%{operatingsystem}"
- "os/%{osfamily}"
- common
:backends:
- yaml
:yaml:
:datadir: /etc/puppet/data
For the folder structure you can use any fact, that you can see in output of facter -y. e.g. you can have hiera config files for each CPU architecture. Then you would add line
- "arch/%{::architecture}"
and hiera would look let's say into arch/amd64.yaml
To debug hiera you can dump your current facts:
$ facter -y > myhost.yaml
And look for some variable:
$ hiera -y myhost.yml snmp_location --debug
Hiera will go through all rules and try to find the variable:
DEBUG: Mon Nov 11 11:00:23 +0100 2013: Hiera YAML backend starting
DEBUG: Mon Nov 11 11:00:23 +0100 2013: Looking up snmp_location in YAML backend
DEBUG: Mon Nov 11 11:00:23 +0100 2013: Looking for data source host/myhost.example.com
...
DEBUG: Mon Nov 11 11:00:23 +0100 2013: Looking for data source ops/Ubuntu
DEBUG: Mon Nov 11 11:00:23 +0100 2013: Cannot find datafile /etc/puppet/data/ops/Ubuntu.yaml, skipping
For matching $::clientcert it might be good idea to extract the top domain to a separate fact and then just have yaml files for cert/example1.org.yaml which would contain something like this:
---
snmp_location: 'Example Org 1'
It's good to know, that even if you have module that doesn't contain any hiera function call at all you can easily setup parameter values:
class snmp (
$location = 'foo',
) {
# ...
}
some hiera config:
---
snmp::location: 'Example Org 1'
Best Answer
On the server hosting your puppet master, run
puppet master --debug --compile yournode.example.com | grep hiera