The Puppet Labs Issue Tracker has Moved:

Bug #5761

Default values are not fully evaluated by the compiler

Added by David Schmitt over 3 years ago. Updated 11 months ago.

Status:AcceptedStart date:01/04/2011
Priority:NormalDue date:
Assignee:-% Done:


Target version:-
Affected Puppet version:2.6.3 Branch:
Keywords:export collect tags defaults customer

We've Moved!

Ticket tracking is now hosted in JIRA:

This ticket may be automatically exported to the PUP project on JIRA using the button below:


File { tag => 'sc_test' }
@@file {
    "/tmp/test1": ensure => present;
    "/tmp/test2": ensure => present, tag => 'sc_test';
File <<| tag == 'sc_test' |>>

# ls -la /tmp/test*
-rw-r--r-- 1 root root 0 Jan  3 14:28 /tmp/test2

From my understanding, the defaults statement in the first line should ensure that both files are tagged ‘sc_test’. As can be seen from the results, only the explicitly tagged resource is collected. This can also be observed with other parameters.

The resource gets written into the stored configs database and other nodes can collect both files.

Related issues

Duplicated by Puppet - Bug #20014: Resource default of 'tag' doesn't propagate Duplicate
Duplicated by Puppet - Bug #20602: Resources tagged using a resource default are not realize... Duplicate
Blocked by Puppet - Bug #3845: Resource defaults and automatic tags are applied after co... Accepted 05/21/2010


#1 Updated by Ben Hughes over 3 years ago

  • Status changed from Unreviewed to Accepted
  • Assignee set to Ben Hughes

Interesting. Thank you for the good example code.

What’s weirder still is the following:

[ben@paresthesia:~]% cat scope.pp    
File { tag => 'dave' }
File { tag => 'sc_test' }

@file {
    "/tmp/test1": ensure => present;
    "/tmp/test2": ensure => present, tag => 'sc_test';

File <| tag == 'sc_test' |>

(I made it virtual, rather than exported, just to remove one element of working.) and you get:

[ben@paresthesia:~]% puppet apply -v scope.pp
info: Connecting to sqlite3 database: /Users/ben/.puppet/var/state/clientconfigs.sqlite3
Default already defined for File { tag }; cannot redefine at /Users/ben/scope.pp:2 on node

Adding in more debug as I go, it’s weird, it’s being set.

debug: File[/tmp/test1]: Adding default for tag
debug: File[/tmp/test1]: Param is at tag => sc_test

#2 Updated by Ben Hughes almost 2 years ago

  • Status changed from Accepted to Unreviewed
  • Assignee deleted (Ben Hughes)

#3 Updated by eric sorenson almost 2 years ago

  • Status changed from Unreviewed to Needs More Information
  • Assignee set to David Schmitt

David this got remanded back to the triage pile — can you please try to determine if this is still an issue in Puppet 3?

#4 Updated by eric sorenson almost 2 years ago

I should also say: if it is, please assign it back to me; if not just mark it closed.

#5 Updated by David Schmitt over 1 year ago

  • Assignee changed from David Schmitt to eric sorenson

Hi eric,

I can confirm that the original problem still persists on 3.0.1, using puppetdb. the latter should make it much easier to debug, but I’m seriously lacking tuits currently.

#6 Updated by Charlie Sharpsteen over 1 year ago

  • Category changed from exported resources to compiler
  • Status changed from Needs More Information to Duplicate

Unfortunately, the compiler currently applies resource defaults and automatic tags after collectors have been evaluated. Marking as a duplicate of #3845.

#7 Updated by Charlie Sharpsteen over 1 year ago

  • Subject changed from a local collect ignores default values to Default values are not fully evaluated by the compiler
  • Status changed from Duplicate to Accepted
  • Assignee deleted (eric sorenson)

It turns out that this is actually a separate issue. This situation is affected by the ordering of compiler run stages as mentioned mentioned in #3845, but there is something else going on.

Resource defaults are merged in when finish is called on resources by the compiler which leads to the add_defaults method in parser/resource.rb:

def add_defaults
  scope.lookupdefaults(self.type).each do |name, param|
    unless @parameters.include?(name)
      self.debug "Adding default for #{name}"

      @parameters[name] = param.dup

This method loops over each default and adds values to the @parameters hash if they are unset. No more, no less. The problem is that simply altering the @parameters hash isn’t sufficient to trigger the full effect of a resource parameter—-the value must be present in the hash when the resource is evaluated by the compiler. As an example, consider the following manifest:

Notify{ tag => 'default_tag' }
notify{ 'hello, compiler!': }

Drop a pry shell at the end of the compile method in parser/compile.rb and inspect what happens:

[root@puppetmaster vagrant]# puppet apply default_tag.pp

From: /puppetlabs/puppet/lib/puppet/parser/compiler.rb @ line 108 Puppet::Parser::Compiler#compile:

     91: def compile
     92:   # Set the client's parameters into the top scope.
     93:   Puppet::Util::Profiler.profile("Compile: Set node parameters") { set_node_parameters }
     95:   Puppet::Util::Profiler.profile("Compile: Created settings scope") { create_settings_scope }
     97:   Puppet::Util::Profiler.profile("Compile: Evaluated main") { evaluate_main }
     99:   Puppet::Util::Profiler.profile("Compile: Evaluated AST node") { evaluate_ast_node }
    101:   Puppet::Util::Profiler.profile("Compile: Evaluated node classes") { evaluate_node_classes }
    103:   Puppet::Util::Profiler.profile("Compile: Evaluated generators") { evaluate_generators }
    105:   Puppet::Util::Profiler.profile("Compile: Finished catalog") { finish }
    107:   fail_on_unevaluated
 => 108:   require 'pry'; binding.pry
    109:   @catalog
    110: end

[1] pry(#)> resources
=> [Class[main]{}, Notify[hello, compiler!]{:tag=>"default_tag"}]

[2] pry(#)> resources[1].tagged?('notify')
=> true

[3] pry(#)> resources[1].tagged?('default_tag')
=> false

[4] pry(#)> resources[1].tags
=> ["notify", "class"]

The notify resource has the :tag parameter set to ‘default_tag’ as expected. However, this parameter wasn’t set when the resource was evaluated by the compiler and thus isn’t part of the tags array attached to the resource. Because of this, the tagged? function doesn’t recognize ‘default_tag’ as being attached to the resource. The upshot is that anything that uses tagged? to filter resources, such as a Transaction applying the catalog, won’t be able to recognize parameters that are set via resource defaults.

This will affect any parameter that produces a side effect during evaluation by the compiler.

#8 Updated by Charlie Sharpsteen over 1 year ago

  • Keywords changed from export collect tags defaults to export collect tags defaults customer

Also available in: Atom PDF