On Thursday, October 18, 2018 at 6:57:41 AM UTC-5, Eirik Øverby wrote:
>
> > class foo:bar(
> > $param1, # This enables you to provide 'param1' when
> instantiating the class,
> > # and it enables auto-parameter-lookup for
> foo::bar::param1 in Hiera.
> > # if no value is given or found in Hiera, the value of
> $param1 will be undef.
> >
> > $param2='test' # This enables you to provide 'param2' when
> instantiating the class,
> > # and it enables auto-parameter-lookup for
> foo::bar::param2 in Hiera.
> > # if no value is given or found in Hiera, the value of
> $param2 will be 'test'.
> > ) { ... }
> >
> > In other words, specifying =<some value> after a parameter in the class
> parameter definition, will enable you to provide a default value that is
> used as a last resort.
>
> Really? We just had to modify about 20 classes in our end because the
> hiera values were *not* used when defaults were specified in the class
> definitions.. Is there some obscure option/setting we've inherited from
> puppet2/3 that we're being bitten by?
>
>
No, there is no option or setting that modulates this behavior. It has
always worked that way, from the time automated data binding was introduced
in Puppet 3, and it has always been the intended (and IMO sensible)
behavior.
I speculate that you've confused the semantics of class *definitions* with
those of resource-like class *declarations*. What you presented is the
skeleton of a class definition, and a simple completion of it might be
class foo:bar ( $param1, $param2='test' ) {
notify { 'foo::bar params':
msg => "param1 = ${param1}, param2 = ${param2}"
}
}
That simply defines what class foo::bar means. It is roughly analogous to
a function or method definition in many general-purpose programming
languages.
The corresponding analogue of a function *call*, on the other hand, is a
class declaration. There are two kinds, "include-like" and
"resource-like". The first is performed via an include, require, or contain
statement, and does not provide a means to express class parameter values
in the manifest. For example,
include foo::bar
That is preferable in many contexts, but it is also possible to declare
classes as if "class" were a resource type:
class { 'foo::bar ':
# Parameter and metaparameter bindings may appear here, such as:
param1 => 42
}
Either way, every class parameter must be bound to a value. Puppet
determines each parameter's value by checking the following sources, in
order:
1. The value specified in a resource-like class declaration has highest
precedence if such a value exists. This is what I suspect you had in mind.
2. The Puppet data lookup facility (a generalization of Hiera)
3. The default value provided by the class definition, if any.
The first source from which a value for the parameter can be obtained is
used, and if none of those provides a value then the catalog builder
bails. Thus, if you want a value from Hiera to be used for parameter
$foo::bar::param2 then in addition to providing such a value in the data,
you must ensure that any resource-like declaration of the class that is
evaluated avoids binding a value to that parameter. And this is the same
thing I was saying in my earlier response.
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/b8656471-bc16-4284-b8e2-8f326db3dc36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
