On Tuesday, February 23, 2016 at 3:29:38 AM UTC-6, Andreas Zuber wrote:
>
> Hello
>
> I recently came across a module where I had the following problem:
>
> I have some arrays with OS specific defaults which get written into a
> config file via template. The user of the module may want to do one of
> the following things:
>
> 1. Use the default settings provided by the module
> 2. Completely overwrite the array
> 3. Append some values to the array from a hiera_array lookup
> 4. Overwrite the defaults and Append some values to the array from a
> hiera_array lookup
>
> I wondered if there is an easy solution to this or an already
> established pattern. The code I came up with which implements all the
> requirements above looks something like this:
>
> manifests/init.pp
> class example (
> $myvar = $example::params::myvar,
> ) inherits example::params {
> notify{$myvar: }
> }
>
> manifests/params.pp
> class example::params {
>
> $myvar_defaults = [
> 'some',
> 'actual',
> 'defaults',
> ]
>
> $myvar_real_defaults = hiera('example::myvar_defaults',
> $myvar_defaults)
> $myvar_append = hiera_array('example::myvar_append', [])
> $myvar = $myvar_real_defaults + $myvar_append
> }
>
> Here is how this works for the requirements:
>
> 1. Simply use the class
> 2. Completely overwrite by setting the class parameter example::myvar as
> usual
> 3. Values set in hiera for variable example::myvar_append will be
> appended to example::myvar
> 4. Setting example::myvar_defaults (priority lookup) will overwrite the
> defaults but still append example::myvar_append
>
> Would be great if I can get some feedback on this. Is there a simpler
> solution I missed? Is this too confusing to be useful at all? Is there
> an already established pattern as a solution to this problem I should
> use instead?
>
If I understand you correctly, you are dividing the wanted data into two
pieces, one of which has a static default and must be subject to priority
lookup, and the other of which must be subject to an array-merge lookup.
This naturally maps to two different Hiera keys. Moreover, I suppose you
are targeting a master older than v4.3.0, since v4.3.0 has the resolution
for PUP-5395 <https://tickets.puppetlabs.com/browse/PUP-5395>, and that
would make it pretty straightforward to implement a solution based simply
on two class parameters.
With that said, I don't think your solution is too bad, but as a stylistic
consideration I do think it's poor form to put much logic into params
classes. Personally, I would instead put most of it into the main class:
class example::params {
$myvar_defaults = [
'some',
'actual',
'defaults',
]
}
class example(
$myvar = $example::params::myvar
) inherits example::params {
$myvar_append = hiera_array('example::myvar_append', [])
$myvar_full = $myvar + $myvar_append
}
Of course, your template would then interpolate values from
$example::myvar_full instead of from $example::myvar. That's slightly
simpler code-wise, uses one fewer Hiera key, and I account it better
style. Moreover, it doesn't muddle with the natural idea of "defaults", as
your code does. All four of your use cases are supported.
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/2742b0f2-5cbf-4fdb-a968-be430fe15d3d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
