File 0002-Refactor-watchdog-fencing-convenience-function-pcmk_.patch of Package pacemaker.36842

From f2cc2a4277124230903a18713e50604a8f1842cd Mon Sep 17 00:00:00 2001
From: Klaus Wenninger <klaus.wenninger@aon.at>
Date: Wed, 1 Mar 2023 15:00:15 +0100
Subject: [PATCH 2/3] Refactor: watchdog-fencing: convenience function
 pcmk__is_fencing_action

for consistency and add comment making clear why this block exits
with new timer set in any case
---
 daemons/fenced/fenced_remote.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/daemons/fenced/fenced_remote.c b/daemons/fenced/fenced_remote.c
index aab185adb..e0f8de057 100644
--- a/daemons/fenced/fenced_remote.c
+++ b/daemons/fenced/fenced_remote.c
@@ -1834,7 +1834,7 @@ request_peer_fencing(remote_fencing_op_t *op, peer_device_info_t *peer)
         if (!((stonith_watchdog_timeout_ms > 0)
               && (pcmk__str_eq(device, STONITH_WATCHDOG_ID, pcmk__str_none)
                   || (pcmk__str_eq(peer->host, op->target, pcmk__str_casei)
-                      && !pcmk__str_eq(op->action, "on", pcmk__str_none)))
+                      && pcmk__is_fencing_action(op->action)))
               && check_watchdog_fencing_and_wait(op))) {
 
             /* Some thoughts about self-fencing cases reaching this point:
@@ -1854,6 +1854,9 @@ request_peer_fencing(remote_fencing_op_t *op, peer_device_info_t *peer)
                  Otherwise the selection of stonith-watchdog-timeout at
                  least is questionable.
              */
+
+            /* coming here we're not waiting for watchdog timeout -
+               thus engage timer with timout evaluated before */
             op->op_timer_one = g_timeout_add((1000 * timeout_one), remote_op_timeout_one, op);
         }
 
-- 
2.35.3