On Oct 28, 10:07 am, Baptiste Grenier <[email protected]>
wrote:
> I am trying to define the modules' run order like this:
You are running up against a common source of confusion: the
difference between order of manifest evaluation (on the master) and
order of catalog application (on the client). You appear to be
conflating the two into "run order", but in general there is no need
for them to be the same, and indeed, one sometimes wants them to
differ.
Evaluation order affects (only) the compilation of your manifests into
a catalog, and the key mechanisms available for influencing it are
(1) the 'require' and 'include' functions (*not* the 'require'
resource metaparameter), and
(2) lexical order within individual manifest files
Application order affects (only) the order in which resources are
applied to your nodes, but that's irrelevant if catalog compilation
fails. The user-accessible mechanisms for influencing it are
(1) the 'require' resource metaparameter and its friends,
(2) the arrow syntax for defining resource relationships,
(3) run stages, and
(4) the 'require' function (which also affects order of manifest
evaluation)
You have an evaluation order problem, and you have tried to fix it by
constraining the application order. Instead, you want something like
this:
[...]
class sudo {
# KEY CHANGE:
include "aptdater::client"
file { '/tmp/sudoers':
ensure => 'present',
content => template('/tmp/sudoers.erb'),
}
notify { "class_sudo": message => "class sudo" }
}
[...]
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
