Hello Jones, thanks for your answer.
Le 10/06/2011 16:20, jcbollinger a écrit :
> If you want to trigger more than one action that is not simply a
> Puppet result message in your log, then your options are:
>
> 1) Make a custom fact out of your command (it's not hard), and use a
> Puppet conditional based on that fact to control which resources are
> included in the node's catlog. This works well, but (a) the command
> will be run before every Puppet run; (b) it captures the command
> result *before* the Puppet run.
making it unappropriate: I need to test the new configuration file.
> 2) Make a custom function to perform the command. This is a bit more
> complicated and a bit more flexible, but it has some significant
> limitations, most importantly: (a) the command is run on the *master*.
same issue.
> 3) Put it all in an Exec. The "onlyif" and "unless" parameters can
> help (for instance, put the real command in an "unless" and the notify
> command in "command"), or you can script the whole thing and exec
> that. This is ugly.
Indeed :)
> 4) Use Puppet resource dependencies, perhaps in combination with one
> or more of the above. If resource A has a declared dependency on
> resource B, and resource B fails, then resource A will not be applied.
That's the one below.
> 5) If your Ruby-fu is strong, then write a custom type and provider
> that do whatever you want.
That's a potential future choice.
> I don't read CFengine, but the following Puppet example might do
> something similar to your CFE code:
>
> file { "/etc/dhcpd.conf":
> # appropriate properties ...
> }
>
> exec { "check_dhcpd_conf":
> command => "/usr/sbin/dhcpd -t /etc/dhcpd.conf",
> refreshonly => true,
> subscribe => File[ "/etc/dhcpd.conf" ]
> }
>
> service { "dhcpd':
> ensure => "running",
> # other parameters as appropriate ...
> require => Exec[ "check_dhcpd_conf" ],
> subscribe => File[ "/etc/dhcpd.conf" ]
> }
Yes, that's I finally opted for, without having the time to test. The
documentation wasn't very clear about impact of failures on
dependencies, but I assumed they were preventing depended resources to
run (http://docs.puppetlabs.com/learning/ordering.html merely speaks
about ordering).
However, the limitation of this pattern is that it doesn't trigger any
alert in case of failure. I still can parse execution logs, or pay
attention to dashboard results for errors, but that's not pushing error
notifications anymore.
--
BOFH excuse #368:
Failure to adjust for daylight savings time.
--
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.
