2013/4/4 jcbollinger <john.bollin...@stjude.org>
> [...]
> 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.
>
the idea behind this example was to write a module that could be used with
Puppet v2.6 and above and that should be able to run in nearly every
environment without modifications. So, if I only look at my
infrastructure, we are talking about ENC provided by foreman. But when I
rewrite my classes I have the goal to write classes that could work in any
other environment as well, regardless if ENC is used or something different.
[...]
>
> 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.
> [...]
>
So from this perspective I would tend to drop hiera completely for now
and thing about hiera support later on again. So I would simply go for an
approach like this:
class example (
$parameter1 = $example::params::parameter1,
$parameter2 = $example::params::parameter2)
inherits example::params {
# Some coding
}
which should give me the maximum of flexibility at this point in time. So
predefined values in a separate params class (all configuration at one
point) that could be touched directly if necessary or that could be
overwritten by an ENC.
Are there any mistakes in my thoughts or is it a good and valid approach?
Regards Thomas
--
Linux ... enjoy the ride!
--
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.
