learning puppet 5 -- ordering

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 1class 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 2class 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 writeclass {'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"