人偶定义的类型的资源是否在标准资源之后进行评估？

Question

When I run the following puppet manifest using puppet 2.7.22:

Exec {
  logoutput => true,
  path      => '/bin',
}

define c {
  exec {"echo [two]: ${b::x}": }
}

class a {
  exec {"echo [one]: ${b::x}": }
  include b
}

class b { $x = "asdf" }

c {'two': }
class {'a': }

I receive the following output:

$ puppet apply test.pp
warning: Scope(Class[A]): Could not look up qualified variable 'b::x'; class b has not been evaluated at /tmp/l/a.pp:11
warning: Scope(Class[A]): Could not look up qualified variable 'b::x'; class b has not been evaluated at /tmp/l/a.pp:11
notice: /Stage[main]//C[two]/Exec[echo [two]: asdf]/returns: [two]: asdf
notice: /Stage[main]//C[two]/Exec[echo [two]: asdf]/returns: executed successfully
notice: /Stage[main]/A/Exec[echo [one]: ]/returns: [one]:
notice: /Stage[main]/A/Exec[echo [one]: ]/returns: executed successfully
notice: Finished catalog run in 0.15 seconds

Now I understand that the puppet evaluates variables in parse order. I understand that it's silly to include the class b from class a after the exec which uses b's x variable. The thing I don't understand is why the exec from the defined type c (instance with name 'two') has an evaluated version of $b::x even though it appears before class 'a' in terms of parse-order.

The only thing that would explain this would be if defined types have get delayed in terms of when they are parsed? If this is the case, is there any documentation from puppetlabs on this (or anywhere) and/or which part of the source differentiates standard from defined type resources? (I've tried finding it in compiler.rb but failed).

Answer 1

Use before or require if you have resource dependencies that need to executed in order:

http://docs.puppetlabs.com/learning/ordering.html#before-and-require

Answer 2

You can fix this problem using require:

define c {
  require b
  notify {"echo [two]: ${b::x}": }
}

class a {
  require b
  notify {"echo [one]: ${b::x}": }
}

class b { $x = "asdf" }

c {'two': }
class {'a': }

Why the defined type doesn't get that warning is unknown to me and frankly I don't really care; it depends on the way the Puppet compiler works. If your manifest depends on such code it might break with the next version of Puppet.