learning puppet 5 -- ordering

8244

Metaparameters

Each resource type has its own set of attributes, but there's another set of attributes, called metaparameters, which can be used on any resource.
There are four metaparameters that let you arrange resources in order:   before, require, notify and subscribe.
Before and Require

before and require make simple dependency relationships, where one resource must be synced before another. before is used in the earlier resource, and lists
resources that depend on it; require is used in the later resource, and lists the resources that it depends on.
Note that these two keywords just define the order between the resources and no more.
for example：
file { '/etc/ssh/sshd_config':
ensure => file,
mode => 600,
source => 'puppet:///modules/ssh/sshd_config',
}
service { 'sshd':
ensure => running,
enable => true,
require=> File['/etc/ssh/sshd_config'],
}

The above code define that resource Service['sshd']  should be synced after File['/etc/ssh/sshd_config']. But if the  File['/etc/ssh/sshd_config'] want  to "refresh" (eg the content of sshd_config have
changed), it will not tell Service['sshd'],and the Service['sshd'] won't resynced because there is no event to drive that(eg: Service['ssdh'] state is still running, so it has no need to change ). If you want the Service refresh with
File, you can use two following keywords "notify" and "subscribe".
Notify and Subscribe

A few resource types (service, exec, and mount) can be "refreshed" — that is, told to react to changes in their environment. For a service, this usually means
restarting when a config file has been changed; for an exec resource, this could mean running its payload if any user accounts have been changed. (Note that refreshes are performed by Puppet, so they only occur during Puppet runs.)
The notify and subscribe metaparameters make dependency relationships the way before and require do, but they also make notification relationships. Not only
will the earlier resource in the pair get synced first, but if Puppet makes any changes to that resource, it will send a refresh event to the later resource, which will react accordingly.
From the above example, we can make a notification relationship :
file { '/etc/ssh/sshd_config':
ensure => file,
mode => 600,
source => 'puppet:///modules/ssh/sshd_config',
}
service { 'sshd':
ensure => running,
enable => true,
subscribe => File['/etc/ssh/sshd_config'],
}

In this example, the sshd service will be restarted if Puppet has to edit its config file.
Chaining Arrows

There's one last way to declare relationships: chain resource references with the ordering (->) and notification (~>; note the tilde) arrows. Think of them as representing the flow of time:
the resource behind the arrow will be synced before the resource the arrow points at.


for example:
file {'/tmp/test1':
ensure => present,
content => "Hi.",
}
notify {'after':
message => '/tmp/test1 has already been synced.',
}
File['/tmp/test1'] -> Notify['after']
Ordering for class

Note that ordering can be used at the level class, that means you can arrange the order relative to a collection of resources or between collections of resources.
# ordering for class example 1
class test_1{
file{'/root/test_1':
ensure=>directory,
}
}
class test_2{
file{'/root/test_1/test_2':
ensure=>present,
content=>'test_2',
require=>Class['test_1'],
}
}as you can see ,you arrange Class['test_1'] (a collection of resources) before File['/root/test_1/test_2'],
# ordering for class example 2
class test_1{
file{'/root/test_1':
ensure=>directory,
}
}
class test_2{
file{'/root/test_1/test_2':
ensure=>present,
content=>'test_2',
}
}
#in other pp file,you can write
class {'test_2':
require=>Class['test_1'],
}
class {'test_1': }
This time, you arrange order between classes!
Ordering for resources in other class

From the example -- "# ordering for class example 1 " , we can arrange orders of resources between different classes. But somtimes, we may just want to ensure the  order for one or more resources
in other classes. Like:
class test_1{
file{'/root/test_1':
ensure=>directory,
}
……
}
class test_2{
file{'/root/test_1/test_2':
ensure=>present,
content=>'test_2',
require=>File['/root/test_1'],
}
}
Note that the above codes is buggy.And because there is too much things to talk about topic , I put the answer  on my article "Access resources from other
class"