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.