Style - hiera/params/puppet/template

[Sirtaj Singh Kang]

Greetings all,

In the pre-hiera days, it was commonly recommended to write classes with
params like this:

class my_class::params {
$config_param = 'default value'
}

class my_class (
$config_param = $myclass:params::config_param
) inherits myclass::params {
...
}

However, now that much overriding, customising etc has moved into Hiera,
this ends up being very verbose, redundant and error-prone, especially
if there are a lot of parameters (to go into a config template, for
example). The same parameter name may end up in four different places in
common cases: hiera, params, class decl and the config template.

So I would like to know if people are still doing this as much as
possible. What is the remaining benefit in declaring defaults in params
rather than in the class declaration directly? Is there a more up to
date style guide that does away with the verbosity and duplication, or
is the old params class style still widely recommended?

Thanks for any suggestions,

-Taj.

[Poil]

Hi,

 I use params_lookup (lib from puppi) https://github.com/example42/puppi/blob/master/lib/puppet/parser/functions/params_lookup.rb
it lookup in this order (first match is returned)
- Hiera backend (if present) for modulename_varname
- Hiera backend (if present) for varname (if second argument is 'global')
 - Top Scope Variable ::modulename_varname
 - Top Scope Variable ::varname (if second argument is 'global')
 - Module default: ::modulename::params::varname

So all my classes are based on this tpl :

class my_class::params {
    $config_param = 'default value'
}

class my_class (

    $config_param = params_lookup('config_param'),
    $global_param = params_lookup('global_param','global')
) inherits my_class::params {
    ...
}

Best regards,

[Atom Powers]

Poli, that doesn't really solve the problem since the variable values could still come from many places. (Puppet also does some of that lookup automatically, although not as deep.)

This may be relevant: 

https://github.com/ripienaar/puppet-module-data/

I still used parameterized classes with an inherited "defaults.pp"; I'd like to use the above but I need to do some more testing before I'm comfortable deploying it.

--
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/54021880.3090505%40quake.fr.

For more options, visit https://groups.google.com/d/optout.

--
Perfection is just a word I use occasionally with mustard.
--Atom Powers--

[Sirtaj Singh Kang]

On Monday 01 September 2014 05:39 AM, Atom Powers wrote:
> Poli, that doesn't really solve the problem since the variable values
> could still come from many places. (Puppet also does some of that
> lookup automatically, although not as deep.)

Yes, though my primary goal is simply to reduce unnecessary duplication.
A single added configurable template parameter currently ends up being
in three places even before bringing in hiera, which is
pretty bad.

This whole thing was brought about by my writing parameterized classes
for some of our
internal custom services that have dozens of options in their config
templates, and the manifest file is just
a sea of parameter names.

I think I'm just going to start putting defaults in the class
declaration param list unless they explicitly
require logic to compute, in which case they'll come from the params.

>
> This may be relevant:
> https://github.com/ripienaar/puppet-module-data/

This looks really cool! Thanks for the reference.

-Taj.

[Christopher Wood]

On Mon, Sep 01, 2014 at 12:34:50PM +0530, Sirtaj Singh Kang wrote:
>
> On Monday 01 September 2014 05:39 AM, Atom Powers wrote:
> >Poli, that doesn't really solve the problem since the variable
> >values could still come from many places. (Puppet also does some
> >of that lookup automatically, although not as deep.)
>
> Yes, though my primary goal is simply to reduce unnecessary
> duplication. A single added configurable template parameter
> currently ends up being in three places even before bringing in
> hiera, which is
> pretty bad.
>
> This whole thing was brought about by my writing parameterized
> classes for some of our
> internal custom services that have dozens of options in their config
> templates, and the manifest file is just
> a sea of parameter names.
>
> I think I'm just going to start putting defaults in the class
> declaration param list unless they explicitly
> require logic to compute, in which case they'll come from the params.

I'm glacially pondering moving away from class parameters to using either static variable declarations in classes ($var = 'thing') or the three hiera lookup functions. That way information is either in the pp file or in hiera and it's easy to explain what comes from where. I also have slow catalog compilations and too many hiera levels, and I'm wondering if knocking down the number of hiera lookups will help me more or less than other stuff like shrinking templates and reducing the number of resources. However, the puppet universe seems to love their class parameters and it may be better to go along with the crowd for training reasons. (It would be easier to figure out if a hiera key is used by grepping for it with function usage.)

This may be an interesting thread, much argumentation in all directions:

https://groups.google.com/forum/#!msg/puppet-users/Z-54YAp9YBc/Ny3Z_d3IW04J

> >This may be relevant:
> >https://github.com/ripienaar/puppet-module-data/
>
> This looks really cool! Thanks for the reference.
>
> -Taj.
>

> --
> 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/54041A92.1020708%40gmail.com.