It sounds like you need to read through these:
http://garylarizza.com/blog/2014/02/17/puppet-workflow-part-1/
http://garylarizza.com/blog/2014/02/17/puppet-workflow-part-2/
I don't see why you'd want to remove parameters from classes. They are
pretty critical to having a flexible infrastructure.
Some of the smaller points in those posts which I think are important (in
addition to the general pattern):
- Don't use default values in hiera. If you don't supply (or typo) a
variable name, then the puppet run should fail.
- Don't use automatic hiera lookups. This removes the magic and makes it
more clear to everyone that the data is coming from hiera.
For your config data showing up in other modules, I think you probably want
role or profile modules, and pass in the data as a parameter. Your
roles/profiles should have all the custom stuff in it, not the component
modules.
Also make liberal use of the validate_* functions from stdlib to further
check your parameters have been supplied correctly.
Don't set default values to anything that is inappropriate. If you don't
want a default for your SuperDaemon config and it needs to be explicitly
configured, then you want it to fail if no parameter is given.
❧ Brian Mathis
@orev
On Thu, May 29, 2014 at 1:58 PM, Christopher Wood <
[email protected]> 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.
>
> --
> 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/20140529175818.GA4308%40iniquitous.heresiarch.ca
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
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/CALKwpEw0SPUjxYv1v2HAruacEP1XKUyvUn3dnhaE1No65ix9mQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
