On Thursday, April 4, 2013 5:38:47 AM UTC-5, thbe wrote:
>
> Hi @all,
>
> I've started rewriting some of my modules to achieve separation of logic 
> and data. So I did some standard layout with init.pp and params.pp for 
> default values and parametrized classes for individual configuration like 
> this:
>
> class example (
>   $parameter1 = hiera('example::parameter1', $example::params::parameter1
> ),
>   $parameter2 = hiera('example::parameter2', $example::params::parameter2
> ))
> inherits example::params {
> # Some coding
> }
>
> I
> s this approach generic enough or will a different coding style be a 
> better approach with more use cases in mind? What do you think, any 
> suggestions?
>
>

Code following that template should work equally well in any Puppet from 
v2.6 onward, provided that hiera is installed.  (Hiera is built-in for 
Puppet 3, but it is a separate add-on to Puppet 2).

However, if you are going to go so far as to specify explicit hiera() calls 
for your default values, then I would recommend you just dump class 
parameterization altogether, and if you do so then you can also avoid class 
inheritance (or use it, where needed, for its real purpose):

class example {
  include 'example::params'
  $parameter1 = hiera('example::parameter1', $example::params::parameter1)
  $parameter2 = hiera('example::parameter2', $example::params::parameter2)
# Some coding
}

That loses you the alternative of expressing class data directly in your 
class declarations, but doing so is problematic and always has been.

As for whether default values should be drawn from a separate class in the 
first place, that's partially a question of the usage and meaning of those 
parameters.  If no other class relies on them then I don't see what is 
gained by extracting them to a separate class -- as far as I'm concerned, 
that just obfuscates.  And in most cases probably no other class SHOULD 
rely on those defaults: what they really want is more likely to be 
$example::parameter1, etc..

And that may itself be a reason to prefer the non-parameterized form if 
compatibility with Puppet 2 is desired: it is my vague (and possibly wrong) 
recollection that in some versions of Puppet class parameters could not be 
accessed from other classes (unlike ordinary class variables).

If you don't care about Puppet 2, on the other hand, then explicit hiera 
calls for your parameter defaults are overkill, and possibly even 
redundant.  The non-parameterized form, on the other hand, is no better or 
worse in Puppet 3 than in Puppet 2.


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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to