On Tuesday, April 26, 2016 at 9:38:24 AM UTC-5, Erik Anderson wrote:
>
> On Puppet 4.4.1
>
> I ran the following:
>
> class testingclass(
> $cmd_path = 'PluginDir',
> ){
> $message_ntfy = "cmd_path is set to: ${cmd_path} for ${name}"
> notify { $message_ntfy: }
> }
>
>
> define testingdefine(
> $cmd_path = 'PluginDir',
> ){
> $message_ntfy = "cmd_path is set to: ${cmd_path} for ${name}"
> notify { $message_ntfy: }
> }
>
>
> node default {
>
>
> class {'testingclass':
> cmd_path => undef,
> }
>
>
> testingdefine { 'testingdefinedefaults': }
> testingdefine { 'testingdefineundef':
> cmd_path => undef,
> }
> }
>
> I expect cmd_path to be set to undef for the class and testingdefineundef.
> Instead it looks like all three end up with the same value for cmd_path:
>
> erik.anderson@puppetmaster1:~$ sudo puppet apply test.pp
> Warning: Config file /etc/puppetlabs/code/hiera.yaml not found, using
> Hiera defaults
> Notice: Compiled catalog for sa-sand-puppetmaster1.sa.moneydesktop.com in
> environment production in 0.15 seconds
> Notice: cmd_path is set to: PluginDir for testingclass
> Notice: /Stage[main]/Testingclass/Notify[cmd_path is set to: PluginDir for
> testingclass]/message: defined 'message' as 'cmd_path is set to:
> PluginDir for testingclass'
> Notice: cmd_path is set to: PluginDir for testingdefinedefaults
> Notice: /Stage[main]/Main/Node[default]/Testingdefine[
> testingdefinedefaults]/Notify[cmd_path is set to: PluginDir for
> testingdefinedefaults]/message: defined 'message' as 'cmd_path is set to:
> PluginDir for testingdefinedefaults'
> Notice: cmd_path is set to: PluginDir for testingdefineundef
> Notice: /Stage[main]/Main/Node[default]/Testingdefine[testingdefineundef]/
> Notify[cmd_path is set to: PluginDir for testingdefineundef]/message:
> defined 'message' as 'cmd_path is set to: PluginDir for
> testingdefineundef'
> Notice: Applied catalog in 0.35 seconds
>
> Any ideas on why it is behaving this way and is it intentional?
>
>
As Rob explained, yes, it is intentional. The symbol undef does not
represent a value; rather, it represents the *absence* of any value. You
can use it in some places where a value is expected, to affirmatively
express that you are not providing a value. That is a bit different from
not saying anything about a value at all, but for most purposes the two
alternatives have the same effect. Using undef has some utility for
various kinds of overrides and defaults, but it does not and cannot work
the way you expected.
One way to look at it is that the effect of undef is necessarily localized
to the point where it appears. This must be so because undef is not a
value, and therefore cannot be propagated. Thus, in your example, the undefs
have all the effect they ever will have in the class and resource
declarations where they appear, and the fact that they appear in those
declarations is invisible in the definitions of the corresponding class and
type, where parameter defaults are defined.
Moving on a bit, you have to decide for every a class or resource parameter
whether you want to insist that users of the class / resource provide a
value for that parameter. If so, then you avoid specifying a default value
for that parameter in the class / resource definition. If not, then you do
specify a default. If you want a way to express that the class / resource
should ignore the parameter, then the conventional way is to define a value
that has local significance as a nonsense value. That might be an empty
string, for example, or maybe the string 'UNDEF'. Ideally, this would be
something that could never be a valid value of the parameter. You then
have the choice of making that the parameter default, or documenting its
use for clients of your class / resource type.
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 view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/dd72ed39-3c40-4b45-8233-9116c1e0b1b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
