In addition to dependencies, resources can also enter a similar yet different mutual relation. Remember the pieces of output that we skipped earlier. They are as follows:
root@puppetmaster:~# puppet apply puppet_service.pp --noop
Notice: Compiled catalog for puppetmaster.example.net in environment production in 0.62 seconds
Notice: /Stage[main]/Main/Service[puppet]/ensure: current_value running, should be stopped (noop)
Notice: Class[Main]: Would have triggered 'refresh' from 1 events
Notice: Stage[main]: Would have triggered 'refresh' from 1 events
Notice: Applied catalog in 0.05 seconds
Puppet mentions that refreshes would have been triggered for the reason of an event. Such events are emitted by resources whenever Puppet acts on the need for a sync action. Without explicit code to receive and react to events, they just get discarded.
The mechanism to set up such event receivers is named in an analogy of a generic publish/subscribe queue; resources get configured to react to events using the subscribe metaparameter. There is no publish keyword or parameter, since each and every resource is technically a publisher of events (messages). Instead, the counterpart of the subscribe metaparameter is called notify, and it explicitly directs generated events at referenced resources.
One of the most common practical uses of the event system is to reload service configurations. When a service resource consumes an event (usually from a change in a config file), Puppet invokes the appropriate action to make the service restart.
The following code example shows the relationships between the haproxy package, the corresponding haproxy configuration file, and the haproxy service:
file { '/etc/haproxy/haproxy.cfg':
ensure => file,
owner => ‘root’,
group => ‘root’
mode => ‘0644’
source => ‘puppet:///modules/haproxy/etc/haproxy/haproxy.cfg',
require => Package['haproxy'],
}
service { 'haproxy':
ensure => 'running',
subscribe => File['/etc/haproxy/haproxy.cfg'],
}
If the notify metaparameter is to be used instead, it must be specified for the resource that emits the event:
file { '/etc/haproxy/haproxy.cfg':
ensure => file,
owner => 'root',
group => 'root',
mode => '0644',
source => 'puppet:///modules/haproxy/etc/haproxy/haproxy.cfg',
require => Package['haproxy'],
notify => Service['haproxy'],
}
service { 'haproxy':
ensure => 'running',
}
This will likely feel reminiscent of the before and require metaparameters, which offer symmetrical ways of expressing an interrelation of a pair of resources just as well. This is not a coincidence, these metaparameters are closely related to each other:
- The resource that subscribes to another resource implicitly requires it
- The resource that notifies another is implicitly placed before the later one in the dependency graph
In other words, subscribe is the same as require, except for the dependent resource receiving events from its peer. The same holds true for notify and before.
The chaining syntax is also available for signaling. To establish a signaling relation between neighboring resources, use an ASCII arrow with a tilde, ~>, instead of the dash in ->:
file { '/etc/haproxy/haproxy.cfg': … }
~>
service { 'haproxy': … }
The service resource type is one of the two notable types that support refreshing when resources get notified (the other will be discussed in the next section). There are others, but they are not as ubiquitous.