FAQ
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.

Search Discussions

  • Jcbollinger at Jan 31, 2013 at 3:08 pm

    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJan 30, '13 at 8:22p
activeJan 31, '13 at 3:08p
posts2
users2
websitepuppetlabs.com

2 users in discussion

Jcbollinger: 1 post Edward Sargisson: 1 post

People

Translate

site design / logo © 2022 Grokbase