[MODULES-3715] ensure_resource fails with undef parameter Created: 2016/08/09  Updated: 2016/09/28

Status: Needs Information
Project: Modules
Component/s: stdlib
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Rein Tollevik Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relates to PUP-6613 regression: explicit undef cannot be ... Closed


Since puppet version 4.5.2 the puppet code below fails with a "Duplicate declaration", it worked in 4.5.1 and earlier releases. From the description of PUP-6385 I assume it was caused by the fix to that issue, although I haven't looked into what was actually changed.

puppet apply -e 'define foo($foo) { } ensure_resource("foo", "FOO", { foo => undef }) ensure_resource("foo", "FOO", { foo => undef })'

Comment by Henrik Lindberg [ 2016/08/10 ]

This is (was?) a problem in stdlib regarding the function defined_with_params. https://github.com/puppetlabs/puppetlabs-stdlib/blob/master/lib/puppet/parser/functions/defined_with_params.rb as it is responsible for figuring out if the resource is already defined or not. The change in PUP-6385 filters out all setting of undef in order to get the correct behavior of using the default value when resources are created with an undef attribute value. Check if a newer stdlib version will fix the problem (it looks like it has been fixed).

Comment by Rein Tollevik [ 2016/08/11 ]

The problem was introduced by the change to create_resources() done in puppet 4.5.2 where it now removes undef parameter values. The problem exist using the latest stdlib version (4.12.0). I would argue that the removal of undef parameter values is wrong, as it is now impossible to call create_resources and pass undef as value to parameters with no default value. The following worked prior to puppet 4.5.2 but now fails:

puppet apply -e 'define foo($foo) { } create_resources(foo, { 'FOO' => { foo => undef } })'
Error: Evaluation Error: Error while evaluating a Resource Statement, Foo[Foo[]]: expects a value for parameter 'foo' on node localhost

The issue where undef is passed as a parameter to select the default parameter value should be solved elsewhere, preferably by not specifying parameters at all when the default values are wanted.

Comment by Henrik Lindberg [ 2016/08/11 ]

The same has always been true when creating resources using code in a manifest. Designing resources so that they can only be used by calling create_resources is a really bad idea - and that would be the consequence since you cannot set an attribute of a resource to undef using the puppet language unless it is done as a default value (or automatic data binding). Going the other direction; making it possible to set undef everywhere would have more dramatic impact on existing code.

Comment by Rein Tollevik [ 2016/08/12 ]

Am I understanding you correctly in that you say that non-default parameter values cannot be set to undef using the puppet language? Where is that documented? The following code works perfectly in all puppet versions I have tried:

puppet apply -e 'define foo($foo) {} foo { "FOO": foo => undef }'

If the above is forbidden then it should be documented and enforced by puppet. Is it valid on the other hand then it should also be possible to use create_resources to declare the same resource, which fails as of puppet 4.5.2.

Comment by Henrik Lindberg [ 2016/08/12 ]

that is true - a case that was not apparent when thinking about this. The rule is: if undef is given, a value from data binding or the default value should be used instead of the given value (that is undef cannot trumpf a default), an explicit setting of undef should be honoured if there is no default.

So, seems like there is one case where puppet it is not doing it right caused by filtering out undef values and that we need to reopen that can of worms.

Comment by Henrik Lindberg [ 2016/08/15 ]

PUP-6613 was filed and there is a PR up for that that should fix the problem reported here. The issues with the related stdlib functions remains though even if the fix in PUP-6613 should remove the specific case reported here.

Comment by David Schmitt [ 2016/08/16 ]

Henrik Lindberg can you summarize how create_resources() should work?

Comment by Rein Tollevik [ 2016/09/27 ]

The problem reported here (puppet apply command in the description) still exist with puppet 4.6.1 and stdlib 4.12.0, but is fixed by the MODULES-3543 commit to defined_with_params on github. Any hope for a newer stdlib version sometimes soon?

Comment by David Schmitt [ 2016/09/27 ]

Rein Tollevik there is one planned in two/three weeks. We've still got a little bit of work in the pipeline around the puppet4 upgrader's work.

Comment by Henrik Lindberg [ 2016/09/27 ]

David Schmitt Regarding your question how create_resources should work... not sure how to respond to that. In short - now it works exactly like if the user had used resource expressions. Earlier create_resources had its own code path and it did some things wrong in comparison to how a resource expression works.

Comment by David Schmitt [ 2016/09/28 ]


Generated at Sat Aug 08 17:19:19 PDT 2020 using Jira 8.5.2#805002-sha1:a66f9354b9e12ac788984e5d84669c903a370049.