to me that it's another instance of the global variable problem if it's
used to load values inside some class, and I'd rather not lose the
benefit of being able to check a class "signature" to see immediately
what variables it needs, and having the code fail if any is not provided.
If I'm understanding you right, then I get around that problem using the
%{calling_module} variable passed from hiera-puppet.
For example
class foo::data ( $somevar = hiera("bar") ) {
When used with a hierarchy similar to
%{environment}/%{calling_module} in my
Means I can store all my "foo" variables up into, for example, dev/foo.yaml
It's a nice way to be able to see at-a-glance how "foo" is configured in
my environment, and also helps with ambiguous variable names (eg: $port)
as grouping them this way offers a kind of scope.
Craig
--
Craig Dunn | http://www.craigdunn.org
Yahoo/Skype: craigrdunn | Twitter: @crayfishX
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
