notify resource different between 3 and 4?

39 views
Skip to first unread message

Christopher Wood

unread,
Sep 16, 2016, 1:11:26 PM9/16/16
to puppet...@googlegroups.com
While trying to figure out the reduce function with notice/notify I happened across this thing. It looks like an unquoted array in the notify resource's message only appears as its first array item. Not sure if it's a bug.

I couldn't find any documentation to say if this was intended and I couldn't really tell what the type was doing with the self.should bit. I am not actually a programmer.

$ cat /tmp/xx.pp
$array = ["one", "two", "three"]

notify { 'notify one':
message => "${array}",
}

notify { 'notify two':
message => $array,
}

With puppet 3 I see this:

$ puppet --version
3.8.7
$ puppet apply /tmp/xx.pp
Fact file /etc/facter/facts.d/monit_fail_count was parsed but returned an empty data set
Fact file /etc/facter/facts.d/monit_fail_count was parsed but returned an empty data set
Notice: Compiled catalog for mail82c40.carrierzone.com in environment production in 0.03 seconds
Notice: one
Notice: /Stage[main]/Main/Notify[notify two]/message: defined 'message' as 'one'
Notice: onetwothree
Notice: /Stage[main]/Main/Notify[notify one]/message: defined 'message' as 'onetwothree'
Notice: Finished catalog run in 0.05 seconds

With puppet 4 I see this:

$ puppet --version
4.6.2
$ puppet apply /tmp/xx.pp
Notice: Compiled catalog for cwl.hostopia.com in environment production in 0.09 seconds
Notice: [one, two, three]
Notice: /Stage[main]/Main/Notify[notify one]/message: defined 'message' as '[one, two, three]'
Notice: one
Notice: /Stage[main]/Main/Notify[notify two]/message: defined 'message' as 'one'
Notice: Applied catalog in 0.11 seconds

R.I.Pienaar

unread,
Sep 16, 2016, 1:18:13 PM9/16/16
to puppet-users


----- Original Message -----
> From: "Christopher Wood" <christop...@pobox.com>
> To: "puppet-users" <puppet...@googlegroups.com>
> Sent: Friday, 16 September, 2016 19:10:23
> Subject: [Puppet Users] notify resource different between 3 and 4?

> While trying to figure out the reduce function with notice/notify I happened
> across this thing. It looks like an unquoted array in the notify resource's
> message only appears as its first array item. Not sure if it's a bug.
>
> I couldn't find any documentation to say if this was intended and I couldn't
> really tell what the type was doing with the self.should bit. I am not actually
> a programmer.
>
> $ cat /tmp/xx.pp
> $array = ["one", "two", "three"]
>
> notify { 'notify one':
> message => "${array}",
> }
>
> notify { 'notify two':
> message => $array,
> }
>

yes this is across all resource types, you cant pass a array to the namevar and
produce many resources, you have to do so to the title

Christopher Wood

unread,
Sep 16, 2016, 1:39:35 PM9/16/16
to puppet...@googlegroups.com
I thought both messages would have some variant of [one, two, three].

Also the namevar here is the name parameter.

But then things get even weirder when I try to do things with the namevar:

$ cat /tmp/y.pp
$array = ["one", "two", "three"]

notify { $array:
message => $array,
}

$ puppet apply /tmp/y.pp
Notice: Compiled catalog for cwl.hostopia.com in environment production in 0.04 seconds
Notice: one
Notice: /Stage[main]/Main/Notify[one]/message: defined 'message' as 'one'
Notice: one
Notice: /Stage[main]/Main/Notify[two]/message: defined 'message' as 'one'
Notice: one
Notice: /Stage[main]/Main/Notify[three]/message: defined 'message' as 'one'
Notice: Applied catalog in 0.08 seconds


But this seems like it might be more normal, but then breaks in a manner I did not expect:

$ cat /tmp/z.pp
$array = ["one", "two", "three"]

notify { $array:
name => $array,
message => $array,
}

$ puppet apply /tmp/z.pp
Error: Evaluation Error: Error while evaluating a Resource Statement, Cannot alias Notify[two] to [["one", "two", "three"]] at /tmp/z.pp:3; resource ["Notify", "one", "two", "three"] already declared at /tmp/z.pp:3 at /tmp/z.pp:3:1 on node cwl

The namevar thing works as expected with a file. Feeling more like this is bug now.

$ cat /tmp/a.pp
$array = ["/tmp/one", "/tmp/two", "/tmp/three"]

file { $array:
content => $array,
}

R.I.Pienaar

unread,
Sep 16, 2016, 1:44:43 PM9/16/16
to puppet-users
kind of expected, or just undefined, message should be a string don't give it a array.
but you can see the names got created as per the array so that seems fine to me, if anything
I think it should raise when you pass non string to message


> But this seems like it might be more normal, but then breaks in a manner I did
> not expect:
>
> $ cat /tmp/z.pp
> $array = ["one", "two", "three"]
>
> notify { $array:
> name => $array,
> message => $array,
> }
>
> $ puppet apply /tmp/z.pp
> Error: Evaluation Error: Error while evaluating a Resource Statement, Cannot
> alias Notify[two] to [["one", "two", "three"]] at /tmp/z.pp:3; resource
> ["Notify", "one", "two", "three"] already declared at /tmp/z.pp:3 at
> /tmp/z.pp:3:1 on node cwl

yeah you cant pass arrays to name either - this is the main change here, you used to be able to.
It *is* though creating notify[one] notify[two] etc but then fail because of passing things
into name you shouldnt :)

> The namevar thing works as expected with a file. Feeling more like this is bug
> now.
>
> $ cat /tmp/a.pp
> $array = ["/tmp/one", "/tmp/two", "/tmp/three"]
>
> file { $array:
> content => $array,
> }

it doesnt really, content isnt the namevar. you're passing a array to title thats fine, content
being an array it's probably just going to puts the array into the file as a string

This stuff seems to work though errors can be a LOT better and I think it should be more strict
on the type of things passed to String properties like message

Christopher Wood

unread,
Sep 16, 2016, 1:53:46 PM9/16/16
to puppet...@googlegroups.com
I think I see what you mean, each file just had "/tmp/three" in it anyway. I don't think I would have encountered this if I hadn't been slapping in a quick notify to see what my reduced array had in it.

jcbollinger

unread,
Sep 19, 2016, 9:31:05 AM9/19/16
to Puppet Users


I see a difference between 3.8 and 4.6 with respect to the result of interpolating an array into a string.  In Puppet 3 (and earlier) you get a concatenation of the stringifications of all the elements, whereas in Puppet 4, you get a more formatted representation.  I would have expected such a change to be applied during a major version update -- so between 3.x and 4.0 -- but a quick browse of the release notes does not appear to mention it.

You called out the unquoted array being bound to the 'message' parameter of the second Notify, but that seems to have exactly the same behavior in the two Puppet outputs you present.  In both cases, the message is taken as the first element of the array.  As R.I. observed, you should not bind an array to a parameter that expects a string.  Given that you did so, I think Puppet handled the situation in a reasonable way.  I'm uncertain whether that behavior is documented.


John

R.I.Pienaar

unread,
Sep 19, 2016, 11:03:14 AM9/19/16
to puppet...@googlegroups.com
This is not a puppet behaviour change. Newer Ruby does nicer looking to_s on arrays that's why



You called out the unquoted array being bound to the 'message' parameter of the second Notify, but that seems to have exactly the same behavior in the two Puppet outputs you present.  In both cases, the message is taken as the first element of the array.  As R.I. observed, you should not bind an array to a parameter that expects a string.  Given that you did so, I think Puppet handled the situation in a reasonable way.  I'm uncertain whether that behavior is documented.


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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/eadea0df-b342-47b9-a3e3-daa981d128b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

jcbollinger

unread,
Sep 20, 2016, 9:37:21 AM9/20/16
to Puppet Users


On Monday, September 19, 2016 at 10:03:14 AM UTC-5, R.I. Pienaar wrote:


On 19 Sep 2016, at 15:31, jcbollinger <John.Bo...@stJude.org> wrote:
I see a difference between 3.8 and 4.6 with respect to the result of interpolating an array into a string.  In Puppet 3 (and earlier) you get a concatenation of the stringifications of all the elements, whereas in Puppet 4, you get a more formatted representation.  I would have expected such a change to be applied during a major version update -- so between 3.x and 4.0 -- but a quick browse of the release notes does not appear to mention it.

This is not a puppet behaviour change. Newer Ruby does nicer looking to_s on arrays that's why



I'm prepared to believe that there's no Puppet code change, which would explain why it's not documented in any release notes, but there's certainly an observable behavior difference between the two example runs.  If that is not to be accounted a Puppet behavior change then I suppose it must also be observable with (only) Puppet 3.8 running on different Ruby versions.  That's a nice gotcha if you happen to rely on interpolating arrays (not that I would recommend doing so in any case).

On the other hand, I observe that the current (4.6) Puppet docs document the array interpolation format, independent of underlying Ruby.  That may now be a distinction without much practical difference, but it's the right thing to do: details of the infrastructure -- and especially changes to them -- ought not to leak out into Puppet's user-facing behavior.  This sort of thing will become more important as Puppet continues its movement away from Ruby as the main implementation language.

In any case, inasmuch as the OP was asking about behavioral differences, it is highly relevant that the one observable difference of any significance arises not because of a difference in the version of Puppet, but because of a difference in the version of the Ruby underneath.


John

R.I.Pienaar

unread,
Sep 20, 2016, 9:54:27 AM9/20/16
to puppet-users


----- Original Message -----
> From: "jcbollinger" <John.Bo...@stJude.org>
> To: "puppet-users" <puppet...@googlegroups.com>
> Sent: Tuesday, 20 September, 2016 15:37:21
> Subject: Re: [Puppet Users] Re: notify resource different between 3 and 4?

> On Monday, September 19, 2016 at 10:03:14 AM UTC-5, R.I. Pienaar wrote:
>>
>>
>>
>> On 19 Sep 2016, at 15:31, jcbollinger <John.Bo...@stJude.org <javascript:>>
>> wrote:
>> I see a difference between 3.8 and 4.6 with respect to the result of
>> interpolating an array into a string. In Puppet 3 (and earlier) you get a
>> concatenation of the stringifications of all the elements, whereas in
>> Puppet 4, you get a more formatted representation. I would have expected
>> such a change to be applied during a major version update -- so between 3.x
>> and 4.0 -- but a quick browse of the release notes does not appear to
>> mention it.
>>
>> This is not a puppet behaviour change. Newer Ruby does nicer looking to_s
>> on arrays that's why
>>
>>
>
> I'm prepared to believe that there's no Puppet code change, which would
> explain why it's not documented in any release notes, but there's certainly
> an observable behavior difference between the two example runs. If that is
> not to be accounted a Puppet behavior change then I suppose it must also be
> observable with (only) Puppet 3.8 running on different Ruby versions.
> That's a nice gotcha if you happen to rely on interpolating arrays (not
> that I would recommend doing so in any case).

yeah, and so you would I think, certainly recall people on IRC running into that.

>
> On the other hand, I observe that the current (4.6) Puppet docs document
> the array interpolation format
> <https://docs.puppet.com/puppet/4.6/reference/lang_data_string.html#conversion-of-interpolated-values>,
> independent of underlying Ruby. That may now be a distinction without much
> practical difference, but it's the right thing to do: details of the
> infrastructure -- and especially changes to them -- ought not to leak out
> into Puppet's user-facing behavior. This sort of thing will become more
> important as Puppet continues its movement away from Ruby as the main
> implementation language.

yup, this becomes a specified and supported way to do this and you can probably
expect these to be properly treated in future.

There is additionally massive amount of string formatting stuff now in the language
https://github.com/puppetlabs/puppet-specifications/blob/master/language/types_values_variables.md

Though their usability leaves a lot to be desired, I suppose they are meant to be
used as plumbing for higher order solutions like wrapper functions or something,
I can't imagine anyone using them as is.


> In any case, inasmuch as the OP was asking about behavioral differences, it
> is highly relevant that the one observable difference of any significance
> arises not because of a difference in the version of Puppet, but because of
> a difference in the version of the Ruby underneath.

Yeah, expect less of that as work moves toward C based compilers etc, this
will make pinning every thing down to specified behaviour, good times.

Henrik Lindberg

unread,
Sep 23, 2016, 4:00:30 PM9/23/16
to puppet...@googlegroups.com
On 20/09/16 15:54, R.I.Pienaar wrote:
>
>
> ----- Original Message -----
>> From: "jcbollinger" <John.Bo...@stJude.org>
>> To: "puppet-users" <puppet...@googlegroups.com>
>> Sent: Tuesday, 20 September, 2016 15:37:21
>> Subject: Re: [Puppet Users] Re: notify resource different between 3 and 4?
>
>> On Monday, September 19, 2016 at 10:03:14 AM UTC-5, R.I. Pienaar wrote:
>>>
>>>
>>>
>>> On 19 Sep 2016, at 15:31, jcbollinger <John.Bo...@stJude.org <javascript:>>
>>> wrote:
>>> I see a difference between 3.8 and 4.6 with respect to the result of
>>> interpolating an array into a string. In Puppet 3 (and earlier) you get a
>>> concatenation of the stringifications of all the elements, whereas in
>>> Puppet 4, you get a more formatted representation. I would have expected
>>> such a change to be applied during a major version update -- so between 3.x
>>> and 4.0 -- but a quick browse of the release notes does not appear to
>>> mention it.
>>>
>>> This is not a puppet behaviour change. Newer Ruby does nicer looking to_s
>>> on arrays that's why
>>>
>>>
>>

It was a deliberate change in how interpolation is done. Earlier it was
unspecified and inconsistent. The change was introduced very early in
the life cycle of "future parser", and I believe it was documented then.
When 4.0 was released, many of the language changes were not release
noted. In some cases because it was impossible to define how it used to
work :-). For this particular change, there should probably have been a
note.

>> I'm prepared to believe that there's no Puppet code change, which would
>> explain why it's not documented in any release notes, but there's certainly
>> an observable behavior difference between the two example runs. If that is
>> not to be accounted a Puppet behavior change then I suppose it must also be
>> observable with (only) Puppet 3.8 running on different Ruby versions.
>> That's a nice gotcha if you happen to rely on interpolating arrays (not
>> that I would recommend doing so in any case).
>
The recommendation is to be explicit about how arrays and hashes should
be formatted if they are wanted in String form (Using either String.new
with a suitable format, or using the join function).

> yeah, and so you would I think, certainly recall people on IRC running into that.
>
>>
>> On the other hand, I observe that the current (4.6) Puppet docs document
>> the array interpolation format
>> <https://docs.puppet.com/puppet/4.6/reference/lang_data_string.html#conversion-of-interpolated-values>,
>> independent of underlying Ruby. That may now be a distinction without much
>> practical difference, but it's the right thing to do: details of the
>> infrastructure -- and especially changes to them -- ought not to leak out
>> into Puppet's user-facing behavior. This sort of thing will become more
>> important as Puppet continues its movement away from Ruby as the main
>> implementation language.
>
> yup, this becomes a specified and supported way to do this and you can probably
> expect these to be properly treated in future.
>
Yes, now that it is specified it is part of the API.

> There is additionally massive amount of string formatting stuff now in the language
> https://github.com/puppetlabs/puppet-specifications/blob/master/language/types_values_variables.md
>
> Though their usability leaves a lot to be desired, I suppose they are meant to be
> used as plumbing for higher order solutions like wrapper functions or something,
> I can't imagine anyone using them as is.
>
Yes, the more advanced formatting stuff is intended to be the basic
building blocks for functions. The current support should be compared to
Ruby's Kernel#format. The surface level functionality is easy to use
though - for example things like String('%d', 42)

>
>> In any case, inasmuch as the OP was asking about behavioral differences, it
>> is highly relevant that the one observable difference of any significance
>> arises not because of a difference in the version of Puppet, but because of
>> a difference in the version of the Ruby underneath.
>
> Yeah, expect less of that as work moves toward C based compilers etc, this
> will make pinning every thing down to specified behaviour, good times.
>
Having the Puppet Language specification is key here.

- henrik

--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

Reply all
Reply to author
Forward
0 new messages