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
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/96935c61-a42f-47ee-b0ff-9c810ebf9668%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
