Ask Your Question

integrating basic modules into hiera?

asked 2015-09-15 17:36:21 -0500

chrisjx gravatar image

At my office we use puppet hiera. The general approach has been to use values in the yaml files as the source for variables in the modules which are defined with snippets that look like this:

hiera('some_hiera_variable', '')

The main puppet init.pp is just a small piece of config pointing to hiera backend. All the hosts/nodes are defined in role based YAMLs and invoke various modules with their associated configs and service modules. After that there is a list of value pairs that are used in the modules with the hiera() function.

So when I download modules from sourceforge I note that none I've looked at so far refer to hiera or have variables like the above example.

Is there a way to reference a module's parameters from the hiera and if so, what's the basic approach? For instance, if the module documentation from puppetforge shows blocks like these (that would be defined in a site.pp):

class {'::icinga':
  dbtype     => 'mysql',
  dbhost     => 'localhost',
  dbuser     => 'icinga',
  dbpasswd   => 'icinga',
  dbname     => 'icinga',

icinga::classicui::user {'username':
  passwd => 'HashPa22worD',

  initdb           => true,
  with_classicui   => true,
  enabled_features => ['statusdata', 'compatlog', 'command'],

class { 'apache':
    default_vhost => false,
} does one translate these into hiera definitions? Perhaps there is a tutorial on this subject?

I am reticent to start seeding the module code with hiera() variables because it seems I'll end up with custom code and unable to retrieve module updates that would overwrite my changes.

Sorry to be such a noob on the subject but any tips would be appreciated.

Thanks, Chris.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2015-09-16 15:26:24 -0500

GregLarkin gravatar image

Your instinct to avoid changing the module code is spot-on, because you'll prevent easily upgrading the module in the future.

You have a couple of options to answer your question:

If you use the first option, you can create Hiera data like so, and the Puppet Forge module will automatically find it and use it for its parameter values:

# Note that Hiera keys are named '<classname>:<attrname>'
'icinga::dbtype': 'mysql'
'icinga::dbhost': ''
'icinga::dbuser': 'myuser'
'icinga::dbpasswd': 'helloworld'
'icinga::dbname': 'icinga'

In fact, just declaring the icinga class like so will perform automatic parameter lookup, even though it's not immediately obvious:

include icinga

You'll have to make decision about whether that level of "magic" is suitable or not.

The 2nd option gives you the flexibility to wrap the Puppet Forge module class(es) with your own class and your own parameter list. You can then use automatic parameter lookups on your own class attribute values, or you can define your own key names with a construct like this:

class mywrapper (
  $param1 = hiera('param1'),
  $param2 = hiera('myparam2', ''),
  $param3 = hiera_array('param_array', []),
) {

  # Declare stuff


See how your wrapper class definition is much more flexible than straight automatic parameter lookup? You have control over your key names, which variant of the Hiera lookup you want, default values, etc.

Also notice, that $param4 still falls under the standard automatic parameter lookup conventions, so Puppet will search for a key named mywrapper::param4 in Hiera for that one parameter.

Hope that helps!

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2015-09-15 17:36:21 -0500

Seen: 263 times

Last updated: Sep 16 '15