On Friday, April 5, 2013 3:25:00 AM UTC-5, thbe wrote:
>
> 2013/4/4 jcbollinger <[email protected] <javascript:>>
>
>> [...]
>> 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 by that you mean you want to use only features that are included in the
Puppet core in every version from 2.6 onward, then all use of hiera is out,
including automatic class parameter binding. Dynamic scoping is also out,
except for node 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.
>> [...]
>>
>
> 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?
>
>
I see no reason to hope that Hiera support will ever be integrated into the
Puppet 2 core -- it will always be an add-on to that series. Therefore, if
you revisit the hiera question later then what you will be (re)considering
at that time is whether it is OK for your module(s) to depend on a plug-in
that is not included in the core, and whether the Puppet 2 series needs to
be supported. I think those questions are better answered now. You can
change direction later if the situation warrants, but you should start with
a firm initial position on those questions.
Personally, I think hiera is so valuable that I would not hesitate to make
it a requirement. Many Puppet 2 sites already use it anyway. I would also
consider allowing Puppetlabs's "stdlib" add-in module (which is still an
add-in in Puppet 3).
Also, you are working from the premise that maximum "flexibility" is an
appropriate goal, as manifested in the idea that your customizable class
data must be exposed as class parameters. That premise is not necessarily
wrong, but it is not fundamentally right, either. An alternative premise
could be that your modules should be designed to be as difficult as
possible to misuse, and that might lead to the conclusion that their
outward-facing classes should NOT be parameterized. There is a design
decision that needs to be made here -- it is not a best-practices issue.
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.
