Browse Source

Use resource collector for the fencing -> stonith ordering

Change Ifef08033043a4cc90a6261e962d2fdecdf275650 moved the stonith
property definition to the pacemaker_master node. This means that the
Class['tripleo::fencing'] -> Class['pacemaker::stonith'] ordering
breaks on non-boostrap pacemaker nodes because the pacemaker::stonith
property is not defined there any longer.

Let's fix this by simply using a resource collector and set the ordering
on that instead of adding yet anoth if statement. Ordering on
enablement of stonith is actually more correct formally.

Tested this on a broken setup successfully.

Closes-Bug: #1712605
Change-Id: I616d340bdf75da9d9eb8b83b2e804dff3d07d58e
(cherry picked from commit 17396dcea8)
tags/6.5.2
Michele Baldessari 1 year ago
parent
commit
0694a3d078
1 changed files with 1 additions and 1 deletions
  1. 1
    1
      manifests/profile/base/pacemaker.pp

+ 1
- 1
manifests/profile/base/pacemaker.pp View File

@@ -125,7 +125,7 @@ class tripleo::profile::base::pacemaker (
125 125
       Pcmk_constraint<||> -> Class['tripleo::fencing']
126 126
       Exec <| tag == 'pacemaker_constraint' |> -> Class['tripleo::fencing']
127 127
       # enable stonith after all fencing devices have been created
128
-      Class['tripleo::fencing'] -> Class['pacemaker::stonith']
128
+      Class['tripleo::fencing'] -> Pcmk_property<|title == 'Enable STONITH'|>
129 129
     }
130 130
     # We have pacemaker remote nodes configured so let's add them as resources
131 131
     # We do this during step 1 right after wait-for-settle, because during step 2

Loading…
Cancel
Save