On Wednesday, January 30, 2013 1:51:23 PM UTC-6, Edward Sargisson wrote:
>
> Hi,
>
> I'm trying to reconcile the advice in the Puppet 3 class doc with our
> current use of Hiera. We currently retrieve variables from Hiera in one big
> collection while the Puppet 3 doc seems to indicate storing variables
> without the collection.
>
> For example, we have a module to manage a log indexer. In its init.pp it
> says:
>
> class log_indexer(
> $log_indexer_conf = hiera_hash('log_indexer_conf'),
> ){
>
> class {'log_indexer::config':
> log_indexer_conf => $log_indexer_conf}
> }
>
> One of the templates used says:
>
> cluster.name: <%= @log_indexer_conf['elasticsearch_cluster_name'] %>
>
> The associated log_indexer.yaml for Hiera is:
>
> log_indexer_conf:
> elasticsearch_cluster_name: 'van-test-elasticsearch-cluster'
>
> The Puppet 3 Class(
> http://docs.puppetlabs.com/puppet/3/reference/lang_classes.html#assigning-classes-from-an-enc)
>
> docs say,
> "Be sure to use 3.0-compatible lookup keys (<class name>::<parameter>).
> This will let 2.x users declare the class with include, and their Hiera
> data will continue to work without changes once they upgrade to Puppet 3."
>
> This suggests that we should do the following in the template:
>
> cluster.name: <%= @elasticsearch_cluster_name %>
>
> and that the Hiera yaml should be:
>
> elasticsearch_cluster_name: 'van-test-elasticsearch-cluster'
>
> Should we move that the module::variable style?
Probably. The biggest advantage here is that you can then drop the
explicit hiera lookups, relying instead on the parameter auto-lookup that
is part of Puppet 3's Hiera integration. That provides several advantages,
among them:
- more concise code
- exceptions where you pass non-hiera class parameters stand out (though
you should assiduously avoid such usage)
- you can declare classes via 'include' instead of via
parametrized-style declarations, which is easier on the eyes, stands out
from resource declarations, and is not restricted to declaring each class
only once
The other alternative you might want to consider is to drop class
parametrization altogether, instead issuing the hiera call in the class
body instead of at the point where you declare the class:
class log_indexer {
$log_indexer_conf = hiera_hash('log_indexer_conf');
}
Even then, it would make sense to to use module::variable style so as to
avoid collisions between different modules' data.
> What about when we have a very large number of parameters - do we have to
> declare them in the class definition (which is shy the _conf style might be
> nice) or does auto-lookup mean you don't have to reference them anywhere
> until you actually do the lookup?
>
>
Among other things, autolookup means you don't have to pass parameters
down a chain of classes to get them to the one that actually needs them.
That helps to reduce the number of parameters that the front-end classes
need to define (supposing that you continue with parametrized classes), as
long as you're ok with not being able to override parameter defaults read
from hiera. And you *should* be ok with that.
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 puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
