Puppet – What is Hiera

Hiera is a powerful way to store (class parameter) data outside of your pp files. Hiera also stores this data in a efficient hierarchial structure so to minimize code duplication. This is especially useful when you want to declare a class that requires a lot of class parameters.

For example, Let’s say our user_account’s module’s class requires 5 class parameters. Then if we declare this class across all our nodes, then it will look something like this:

[root@puppetmaster ~]# cat /etc/puppet/manifests/site.pp

node 'PuppetAgent1' {
  class {user_account:
    username => "bart",
    password => "Liverpool",
    password_max_age => "90",
    password_min_age => "10",
    shell => /bin/bash,
  }
}

node 'PuppetAgent2' {
  class {user_account:
    username => "bart",
    password => "Liverpool",
    password_max_age => "90",
    password_min_age => "10",
    shell => /bin/bash,
  }
}

node 'PuppetAgent3' {
  class {user_account:
    username => "bart",
    password => "Liverpool",
    password_max_age => "90",
    password_min_age => "10",
    shell => /bin/bash,
  }
}

As you can see we are passing the same parameter values for these nodes. There’s 2 problems with this. First, if for each node, we need to change the passord parameter from “Liverpool” to another value, e.g. “Manchester”, then that’s going to become tedious. Secondly declaring class’s using the class-syntax takes up a lot of lines of code.

However thanks to Hiera, we can seperate out the class parameter data so that our manifest now looks like this:

  
node 'PuppetAgent1' {
  include user_account
}

node 'PuppetAgent2' {
  include user_account
}

node 'PuppetAgent3' {
  include user_account
}

node 'PuppetAgent4' {
  include user_account
}

This is possible, thanks to hiera. With hiera, all the data is stored in a bunch of yaml files, and then Puppet requests for the data through hiera, which in turn queries the yaml files. Hiera queries the yaml files in “fallback style”. For example you may have heard of the saying:

You always need a plan B, just in case plan A doesn’t work.

Hiera (along with Puppet) takes this concept to the next level, and has plan c, plan d, plan e….and etc. In the context of puppet+hiera, these plans are to do with locating the data, when classes are declared using the “include” statement.

The Hiera lookup order

So when puppet encounters an include statement, but the corresponding class requires class parameters, then the following happens:

  1. puppetmaster asks hiera to find the info.
  2. Hiera then asks puppetmaster for the agent’s facter data and puppet builtin variables. These are available within the manifests node-defintion.
  3. hiera then identifies a list of yaml files that it needs to look through to find the data. This is done through hiera hierarchy. We will cover more about this later.
  4. Hiera then checks if the first file exists (plan A), if it doesn’t exist, or file exist, but file exists but doesn’t have the info, then hiera moves on to the next file, aka plan B.
  5. It repeats the previous process with second file (plan B). And if it fails again, then moves on to the next file, aka plan C. This cycle continues until the data is found, or hiera has run out of yaml files.
  6. if hiera fails to find the data, then it will notify puppetmaster of this by returning “nil”
  7. puppetmaster will then, as a last resort, see if the class has any default parameters defined. If it does, then it will use them instead.
  8. If no default values are defined in the class definitions, then the current puppet run will terminate and an error will be displayed, since the puppetmaster was unable to compile the catalog.

If we reach the last step then it means we need to investigate and fix the issue.

See also:
https://docs.puppetlabs.com/hiera/1/index.html