invoke modules from puppetforge from hiera yamls?

[Chris Jefferies]

At my office we use puppet hiera. The general approach has been to use key value pairs 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', 'www.google.com')

The main puppet init.pp is 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 key 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 (which 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',
}

class{'::icinga':
  initdb           => true,
  with_classicui   => true,
  enabled_features => ['statusdata', 'compatlog', 'command'],
}

class { 'apache':
    default_vhost => false,
}

...how 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.

[Chad Huneycutt]

Take a look at this page:
http://docs.puppetlabs.com/hiera/3.0/puppet.html . The section
entitled "Automatic Parameter Lookup" explains how to specify puppet
class parameters in hiera.

- Chad

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/002b3a69-9f89-4bd6-96de-e9b4b373038c%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Chad M. Huneycutt

[jcbollinger]

On Tuesday, September 15, 2015 at 8:14:05 PM UTC-5, Chris Jefferies wrote:

At my office we use puppet hiera. The general approach has been to use key value pairs 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', 'www.google.com')

The main puppet init.pp is 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 key value pairs that are used in the modules with the hiera() function.

It sounds to me like you are using un-parameterized classes, and relying on Hiera lookups to feed data to them.  If so, then Bravo!  At one time I advocated just such an approach, and I still think it's perfectly viable.  I never could stem the tide of enthusiasm for class parameterization, however, and although there are still some gotchas surrounding parameterized classes, the automated data binding feature introduced in Puppet 3 mitigates the more glaring of those issues.

 

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.

Yet all parameterized classes do use Hiera to lookup values for any parameters that are not set via their declarations (this is automated data binding), and for the most part, class declarations should not set any parameters, nor even use the resource-like class declaration syntax at all.  And of course classes may still perform explicit Hiera lookups, but these days, it is typical for them to rely on data binding instead.  This tends to work well for most purposes.

 

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 (which would be defined in a site.pp):

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

The preceding is a class declaration in the resource-like style.  Generally speaking, don't do that.  Instead, yes, classes can obtain parameter values from Hiera (see Chad's link), and that's how they should obtain them in most cases.

 

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

That, on the other hand, is the declaration of a bona fide resource.  Resource declarations do not participate in automated data binding, and they are not subject to any of the gotchas associated with resource-like class declarations.

 

...how does one translate these into hiera definitions? Perhaps there is a tutorial on this subject?

Chad gave you a link.  Basically, though, it's simple: if class "my_module::a_class" has a parameter "param1", and that class is declared in a manner that does not specify a value for that parameter (for example, via an include-like declaration) then Puppet attempts to look up the value in hiera via key "my_module::a_class::param1".  If that key is not present then Puppet falls back to the declared default value, or fails if no default is declared.

 

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.

You are right to be concerned.  If you are relying on third-party modules (and most people do), then it is wise to avoid forking them, if possible.  Indeed, this is one very good reason for Hiera and externalizing data in the first place.

John