Puppet users - Jan 2013 - Hiera parameter lookup, nesting variables and Puppet 3

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? 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?

Many thanks,
Edward

-- 
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+unsubscribe@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.

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+unsubscribe@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.