On 5/29/2014 10:58 AM, Christopher Wood wrote:
(I'm not sure how to phrase my question precisely, so this may not
all be totally clear.)
Has anybody else successfully moved away from using params.pp and
default values, and if so, what did you do and how did it go? If not,
what made you go back?
The only answer I can come up with is to stop using class parameters,
change to hiera functions, and put all my data defaults in
common.yaml.
The background:
I've had a couple of odd (lab) situations where much troubleshooting
was occasioned by how I misspelled a key name in hiera and thus
configuration data was pulled from a default value (either params.pp
or the parameter default value). If there was no default value I
would simply have gotten an error about the lookup failure and fixed
that quickly.
In a related matter, sometimes I need a piece of configuration data
from one module to appear in another module. Faked-up example, my
SuperDaemon configuration data has to be used by monit to supervise
all the worker daemons and by logrotate to rotate their individual
log files. Some things are data bindings, some are
hiera()/hiera_array()/hiera_hash() on a case by case basis, and it's
messy.
In another related matter, explaining the combination of puppet
inheritance from params.pp, default values, hiera, and hiera
functions makes people's eyes glaze over. It would be easier to point
people at hiera and say "source of data, learn these three
functions".
Things are mostly fine, I may just be wanting to tweak things, but it
strikes me there's a way to do all this with much less effort.
I'm curious about this as well. This was my pre parametrized classes
attempt to make it more understandable. I *think* this was a slight
improvement, but I'm not convinced that it adds much beyond pointing a
user where to look for the data.
class redis::params {
$packagename = $::osfamily ? {
/(?i:debian)/ => 'redis-server',
/(?i:redhat)/ => 'redis',
}
}
class redis::data {
$version = hiera('redis::version','present')
}
class redis::install {
package { $redis::params::packagename:
ensure => $redis::data::version;
}
}
I haven't switched over to parametrized classes mostly because the
above already works, the limited Hiera lookup available to data
bindings, and the great description you provided of the "where is this
data coming from" problem.
My current thinking is somewhat similar to yours. It might make sense
to pull in RI's module data patch and use explicit Hiera calls
everywhere. Data is always provided via Hiera, just from two locations.
The downsides are that PL is likely going to go a different direction
and it's a fair amount of code to change.
However moving the cognitive overhead to the writing of code instead of
the operating of it may be worth it till a better solution presents itself.
Ramin
--
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/5388C38F.9010604%40badapple.net.
For more options, visit https://groups.google.com/d/optout.
