rpms/pacemaker
7
0
Fork 0
Code Issues Pull Requests Releases Activity

import OL pacemaker-3.0.1-3.1.0.1.el10_1

Browse Source
This commit is contained in:
eabdullin 2026-02-26 12:30:19 +00:00
parent 3863a4fbac
commit 3765d79ca8
11 changed files with 1419 additions and 438 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
.gitignore vendored
View File

@ -1,3 +1 @@
/ClusterLabs-pacemaker-*.tar.gz
/[Pp]acemaker-*.tar.gz
/nagios-agents-metadata-*.tar.gz
pacemaker-9a5e54bae.tar.gz

40
001-econnrefused.patch Normal file
View File

@ -0,0 +1,40 @@
From 125b434943f57778816135ad147fc827fa706e99 Mon Sep 17 00:00:00 2001
From: Chris Lumens <clumens@redhat.com>
Date: Mon, 4 Aug 2025 10:38:00 -0400
Subject: [PATCH] Med: libpacemaker: Do not retry on ECONNREFUSED in tools.
This is a regression introduced by e438946787. In that patch, what
we're trying to do is retry IPC connections between daemons. If a
daemon gets ECONNREFUSED when it initiates an IPC connection, the most
likely reason is that another daemon has been killed and is restarting
but is not yet ready to accept connections. Waiting and retrying
repeatedly is an acceptable way to deal with this.
However, if a command line tool gets ECONNREFUSED, it's more likely that
the problem is the cluster isn't running at all. In this case, waiting
and retrying just introduces a delay for a situation that will never be
resolved. Reverting just the part in pcmk_cluster_queries.c should fix
this problem without affecting any of the daemons - they don't call this
code.
Fixes RHEL-106594
---
lib/pacemaker/pcmk_cluster_queries.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/pacemaker/pcmk_cluster_queries.c b/lib/pacemaker/pcmk_cluster_queries.c
index 8a08d99180..2f91a68738 100644
--- a/lib/pacemaker/pcmk_cluster_queries.c
+++ b/lib/pacemaker/pcmk_cluster_queries.c
@@ -360,7 +360,7 @@ ipc_connect(data_t *data, enum pcmk_ipc_server server, pcmk_ipc_callback_t cb,
pcmk_register_ipc_callback(api, cb, data);
}
- rc = pcmk__connect_ipc_retry_conrefused(api, dispatch_type, 5);
+ rc = pcmk__connect_ipc(api, dispatch_type, 5);
if (rc != pcmk_rc_ok) {
if (rc == EREMOTEIO) {
data->pcmkd_state = pcmk_pacemakerd_state_remote;
--
2.49.0

26
001-reset-error-warning-flags.patch
View File

@ -1,26 +0,0 @@
From 78e6b46a2bbb80af24a804045313370a6404a251 Mon Sep 17 00:00:00 2001
From: Hideo Yamauchi <renayama19661014@ybb.ne.jp>
Date: Thu, 9 Jan 2025 08:32:48 +0900
Subject: [PATCH] Mid: schedulerd: Resetting error and warning flags.
---
lib/pengine/status.c | 3 +++
1 file changed, 3 insertions(+), 0 deletions(-)
diff --git a/lib/pengine/status.c b/lib/pengine/status.c
index a97d6f7..87b5f6c 100644
--- a/lib/pengine/status.c
+++ b/lib/pengine/status.c
@@ -447,6 +447,9 @@ set_working_set_defaults(pcmk_scheduler_t *scheduler)
|pcmk__sched_stop_removed_resources
|pcmk__sched_cancel_removed_actions);
#endif
+
+ pcmk__config_has_error = false;
+ pcmk__config_has_warning = false;
}
pcmk_resource_t *
--
2.47.0

75
002-corosync.patch Normal file
View File

@ -0,0 +1,75 @@
From b1fd6ccea9083826c1c2fb40418651704989a904 Mon Sep 17 00:00:00 2001
From: Reid Wahl <nrwahl@protonmail.com>
Date: Wed, 13 Aug 2025 17:33:16 -0700
Subject: [PATCH] Fix: cts: Start corosync using systemd if available
As of corosync upstream commit ae859515, in systemd builds,
StateDirectory is set in the systemd corosync.service file. The corosync
state directory defaults to this value if not set in the corosync config
file. Corosync falls back to using /var/lib/corosync only if the systemd
StateDirectory is not set.
The same commit removes /var/lib/corosync from RPM builds with systemd.
As a result, if corosync was built with systemd, then starting corosync
outside of systemd fails unless /var/lib/corosync has been created
manually or through some other means. Starting corosync directly from
the command line fails with the following error, because the
STATE_DIRECTORY environment variable was not set by systemd:
Cannot chdir to state directory /var/lib/corosync. No such file or
directory
This causes Pacemaker's cts-fencing script to fail.
This seems like a bug in corosync, as it now assumes that corosync will
always be started by systemd if available. Here, we work around it in
cts by doing exactly that.
Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
---
python/pacemaker/_cts/corosync.py | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/python/pacemaker/_cts/corosync.py b/python/pacemaker/_cts/corosync.py
index 0a55dd7c96..beb574d2b8 100644
--- a/python/pacemaker/_cts/corosync.py
+++ b/python/pacemaker/_cts/corosync.py
@@ -11,6 +11,7 @@ import tempfile
import time
from pacemaker.buildoptions import BuildOptions
+from pacemaker._cts.environment import EnvFactory
from pacemaker._cts.process import killall, stdout_from_command
@@ -112,6 +113,9 @@ class Corosync:
self.logdir = logdir
self.cluster_name = cluster_name
+ # The Corosync class doesn't use self._env._nodes, but the
+ # "--nodes" argument is required to be present and nonempty
+ self._env = EnvFactory().getInstance(args=["--nodes", "localhost"])
self._existing_cfg_file = None
def _ready(self, logfile, timeout=10):
@@ -149,10 +153,15 @@ class Corosync:
self.cluster_name, localname())
logfile = corosync_log_file(BuildOptions.COROSYNC_CONFIG_FILE)
+ if self._env["have_systemd"]:
+ cmd = ["systemctl", "start", "corosync.service"]
+ else:
+ cmd = ["corosync"]
+
if self.verbose:
print("Starting corosync")
- with subprocess.Popen("corosync", stdout=subprocess.PIPE, stderr=subprocess.PIPE) as test:
+ with subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE) as test:
test.wait()
# Wait for corosync to be ready before returning
--
2.50.1

353
002-remote-fencing.patch
View File

@ -1,353 +0,0 @@
From a8065dbd5b5e5c56ce05830b2a8bafb40d5a57d4 Mon Sep 17 00:00:00 2001
From: Chris Lumens <clumens@redhat.com>
Date: Fri, 28 Mar 2025 15:04:24 -0400
Subject: [PATCH] Refactor: scheduler: Fix formatting in pe_can_fence.
---
lib/pengine/utils.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/pengine/utils.c b/lib/pengine/utils.c
index 8a2e946c92..acd825b468 100644
--- a/lib/pengine/utils.c
+++ b/lib/pengine/utils.c
@@ -62,10 +62,10 @@ pe_can_fence(const pcmk_scheduler_t *scheduler, const pcmk_node_t *node)
} else if (scheduler->no_quorum_policy == pcmk_no_quorum_ignore) {
return true;
- } else if(node == NULL) {
+ } else if (node == NULL) {
return false;
- } else if(node->details->online) {
+ } else if (node->details->online) {
crm_notice("We can fence %s without quorum because they're in our membership",
pcmk__node_name(node));
return true;
--
2.31.1
From 0912256460730ac5e64c41c72543253518370255 Mon Sep 17 00:00:00 2001
From: Chris Lumens <clumens@redhat.com>
Date: Fri, 28 Mar 2025 15:08:56 -0400
Subject: [PATCH] Med: scheduler: Don't always fence online remote nodes.
Let's assume you have a cluster configured as follows:
* Three nodes, plus one Pacemaker Remote node.
* At least two NICs on each node.
* Multiple layers of fencing, including fence_kdump.
* The timeout for fence_kdump is set higher on the real nodes than it is
on the remote node.
* A resource is configured that can only be run on the remote node.
Now, let's assume that the node running the connection resource for the
remote node is disconnect from the rest of the cluster. In testing,
this disconnection was done by bringing one network interface down.
Due to the fence timeouts, the following things will occur:
* The node whose interface was brought down will split off into its own
cluster partition without quorum, while the other two nodes maintain
quorum.
* The partition with quorum will restart the remote node resource on
another real node in the partition.
* The node by itself will be fenced. However, due to the long
fence_kdump timeout, it will continue to make decisions regarding
resources.
* The node by itself will re-assign resources, including the remote
connection resource. This resource will be assigned back to the same
node again.
* The node by itself will decide to fence the remote node, which will
hit the "in our membership" clause of pe_can_fence. This is because
remote nodes are marked as online when they are assigned, not when
they are actually running.
* When the fence_kdump timeout expires, the node by itself will fence
the remote node. This succeeds because there is still a secondary
network connection it can use. This fencing will succeed, causing the
remote node to reboot and then causing a loss of service.
* The node by itself will then be fenced.
The bug to me seems to be that the remote resource is marked as online
when it isn't yet. I think with that changed, all the other remote
fencing related code would then work as intended. However, it probably
has to remain as-is in order to schedule resources on the remote node -
resources probably can't be assigned to an offline node. Making changes
in pe_can_fence seems like the least invasive way to deal with this
problem.
I also think this probably has probably been here for a very long time -
perhaps always - but we just haven't seen it due to the number of things
that have to be configured before it can show up. In particular, the
fencing timeouts and secondary network connection are what allow this
behavior to happen.
I can't think of a good reason why a node without quorum would ever want
to fence a remote node, especially if the connection resource has been
moved to the quorate node.
My fix here therefore is just to test whether there is another node it
could have been moved to and if so, don't fence it.
---
lib/pengine/utils.c | 33 +++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/lib/pengine/utils.c b/lib/pengine/utils.c
index acd825b468..1822acaa54 100644
--- a/lib/pengine/utils.c
+++ b/lib/pengine/utils.c
@@ -66,6 +66,39 @@ pe_can_fence(const pcmk_scheduler_t *scheduler, const pcmk_node_t *node)
return false;
} else if (node->details->online) {
+ /* Remote nodes are marked online when we assign their resource to a
+ * node, not when they are actually started (see remote_connection_assigned)
+ * so the above test by itself isn't good enough.
+ */
+ if (pcmk__is_pacemaker_remote_node(node)) {
+ /* If we're on a system without quorum, it's entirely possible that
+ * the remote resource was automatically moved to a node on the
+ * partition with quorum. We can't tell that from this node - the
+ * best we can do is check if it's possible for the resource to run
+ * on another node in the partition with quorum. If so, it has
+ * likely been moved and we shouldn't fence it.
+ *
+ * NOTE: This condition appears to only come up in very limited
+ * circumstances. It at least requires some very lengthy fencing
+ * timeouts set, some way for fencing to still take place (a second
+ * NIC is how I've reproduced it in testing, but fence_scsi or
+ * sbd could work too), and a resource that runs on the remote node.
+ */
+ pcmk_resource_t *rsc = node->priv->remote;
+ pcmk_node_t *n = NULL;
+ GHashTableIter iter;
+
+ g_hash_table_iter_init(&iter, rsc->priv->allowed_nodes);
+ while (g_hash_table_iter_next(&iter, NULL, (void **) &n)) {
+ /* A node that's not online according to this non-quorum node
+ * is a node that's in another partition.
+ */
+ if (!n->details->online) {
+ return false;
+ }
+ }
+ }
+
crm_notice("We can fence %s without quorum because they're in our membership",
pcmk__node_name(node));
return true;
--
2.31.1
From b0e6544bbf578285918b69ff9c9b35d2c9f54713 Mon Sep 17 00:00:00 2001
From: Chris Lumens <clumens@redhat.com>
Date: Mon, 9 Jun 2025 14:23:53 -0400
Subject: [PATCH] Med: scheduler: Require a cluster option for old remote
fencing behavior.
If the user wants to preserve the old fencing behavior, where a node
without quorum is allowed to fence remote nodes in the same partition
even if they've been restarted, they need to add
fence-remote-without-quorum="true" to their CIB. Omitting this option
or setting it to false will get the new remote fencing behavior.
---
cts/cli/regression.crm_attribute.exp | 14 ++++++++++++++
cts/cli/regression.daemons.exp | 9 +++++++++
include/crm/common/options.h | 3 ++-
include/crm/common/scheduler_internal.h | 5 +++++
lib/common/options.c | 12 +++++++++++-
lib/pengine/unpack.c | 8 ++++++++
lib/pengine/utils.c | 3 ++-
7 files changed, 51 insertions(+), 3 deletions(-)
diff --git a/cts/cli/regression.crm_attribute.exp b/cts/cli/regression.crm_attribute.exp
index c84860490b..0fff171721 100644
--- a/cts/cli/regression.crm_attribute.exp
+++ b/cts/cli/regression.crm_attribute.exp
@@ -272,6 +272,11 @@ Also known as properties, these are options that affect behavior across the enti
<shortdesc lang="en">Whether the cluster should check for active resources during start-up</shortdesc>
<content type="boolean" default=""/>
</parameter>
+ <parameter name="fence-remote-without-quorum" advanced="1" generated="0">
+ <longdesc lang="en">By default, an inquorate node can not fence Pacemaker Remote nodes that are part of its partition as long as the cluster thinks they can be restarted. If true, inquorate nodes will be able to fence remote nodes regardless.</longdesc>
+ <shortdesc lang="en">Whether remote nodes can be fenced without quorum</shortdesc>
+ <content type="boolean" default=""/>
+ </parameter>
<parameter name="stonith-enabled" advanced="1" generated="0">
<longdesc lang="en">If false, unresponsive nodes are immediately assumed to be harmless, and resources that were active on them may be recovered elsewhere. This can result in a "split-brain" situation, potentially leading to data loss and/or service unavailability.</longdesc>
<shortdesc lang="en">Whether nodes may be fenced as part of recovery</shortdesc>
@@ -598,6 +603,10 @@ Also known as properties, these are options that affect behavior across the enti
* Delay cluster recovery for this much time to allow for additional events to occur. Useful if your configuration is sensitive to the order in which ping updates arrive.
* Possible values: duration (default: )
+ * fence-remote-without-quorum: Whether remote nodes can be fenced without quorum
+ * By default, an inquorate node can not fence Pacemaker Remote nodes that are part of its partition as long as the cluster thinks they can be restarted. If true, inquorate nodes will be able to fence remote nodes regardless.
+ * Possible values: boolean (default: )
+
* stonith-enabled: Whether nodes may be fenced as part of recovery
* If false, unresponsive nodes are immediately assumed to be harmless, and resources that were active on them may be recovered elsewhere. This can result in a "split-brain" situation, potentially leading to data loss and/or service unavailability.
* Possible values: boolean (default: )
@@ -724,6 +733,11 @@ Also known as properties, these are options that affect behavior across the enti
<shortdesc lang="en">Whether the cluster should check for active resources during start-up</shortdesc>
<content type="boolean" default=""/>
</parameter>
+ <parameter name="fence-remote-without-quorum" advanced="1" generated="0">
+ <longdesc lang="en">By default, an inquorate node can not fence Pacemaker Remote nodes that are part of its partition as long as the cluster thinks they can be restarted. If true, inquorate nodes will be able to fence remote nodes regardless.</longdesc>
+ <shortdesc lang="en">Whether remote nodes can be fenced without quorum</shortdesc>
+ <content type="boolean" default=""/>
+ </parameter>
<parameter name="stonith-enabled" advanced="1" generated="0">
<longdesc lang="en">If false, unresponsive nodes are immediately assumed to be harmless, and resources that were active on them may be recovered elsewhere. This can result in a "split-brain" situation, potentially leading to data loss and/or service unavailability.</longdesc>
<shortdesc lang="en">Whether nodes may be fenced as part of recovery</shortdesc>
diff --git a/cts/cli/regression.daemons.exp b/cts/cli/regression.daemons.exp
index 26e9286d58..09c7941fa8 100644
--- a/cts/cli/regression.daemons.exp
+++ b/cts/cli/regression.daemons.exp
@@ -514,6 +514,15 @@
</shortdesc>
<content type="boolean" default=""/>
</parameter>
+ <parameter name="fence-remote-without-quorum">
+ <longdesc lang="en">
+ By default, an inquorate node can not fence Pacemaker Remote nodes that are part of its partition as long as the cluster thinks they can be restarted. If true, inquorate nodes will be able to fence remote nodes regardless.
+ </longdesc>
+ <shortdesc lang="en">
+ *** Advanced Use Only *** Whether remote nodes can be fenced without quorum
+ </shortdesc>
+ <content type="boolean" default=""/>
+ </parameter>
<parameter name="stonith-enabled">
<longdesc lang="en">
If false, unresponsive nodes are immediately assumed to be harmless, and resources that were active on them may be recovered elsewhere. This can result in a "split-brain" situation, potentially leading to data loss and/or service unavailability.
diff --git a/include/crm/common/options.h b/include/crm/common/options.h
index 91016315af..e425aa03d9 100644
--- a/include/crm/common/options.h
+++ b/include/crm/common/options.h
@@ -1,5 +1,5 @@
/*
- * Copyright 2024 the Pacemaker project contributors
+ * Copyright 2024-2025 the Pacemaker project contributors
*
* The version control history for this file may have further details.
*
@@ -37,6 +37,7 @@ extern "C" {
#define PCMK_OPT_ENABLE_ACL "enable-acl"
#define PCMK_OPT_ENABLE_STARTUP_PROBES "enable-startup-probes"
#define PCMK_OPT_FENCE_REACTION "fence-reaction"
+#define PCMK_OPT_FENCE_REMOTE_WITHOUT_QUORUM "fence-remote-without-quorum"
#define PCMK_OPT_HAVE_WATCHDOG "have-watchdog"
#define PCMK_OPT_JOIN_FINALIZATION_TIMEOUT "join-finalization-timeout"
#define PCMK_OPT_JOIN_INTEGRATION_TIMEOUT "join-integration-timeout"
diff --git a/include/crm/common/scheduler_internal.h b/include/crm/common/scheduler_internal.h
index 82805ac4ac..3fa2812b66 100644
--- a/include/crm/common/scheduler_internal.h
+++ b/include/crm/common/scheduler_internal.h
@@ -154,6 +154,11 @@ enum pcmk__scheduler_flags {
* applying node-specific location criteria, assignment, etc.)
*/
pcmk__sched_validate_only = (1ULL << 27),
+
+ /* Can Pacemaker Remote nodes be fenced even from a node that doesn't
+ * have quorum?
+ */
+ pcmk__sched_fence_remote_no_quorum = (1ULL << 28),
};
// Implementation of pcmk__scheduler_private_t
diff --git a/lib/common/options.c b/lib/common/options.c
index 7ed6bd9990..b8f4943fda 100644
--- a/lib/common/options.c
+++ b/lib/common/options.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2004-2024 the Pacemaker project contributors
+ * Copyright 2004-2025 the Pacemaker project contributors
*
* The version control history for this file may have further details.
*
@@ -229,6 +229,16 @@ static const pcmk__cluster_option_t cluster_options[] = {
},
// Fencing-related options
+ {
+ PCMK_OPT_FENCE_REMOTE_WITHOUT_QUORUM, NULL, PCMK_VALUE_BOOLEAN, NULL,
+ PCMK_VALUE_FALSE, pcmk__valid_boolean,
+ pcmk__opt_schedulerd|pcmk__opt_advanced,
+ N_("Whether remote nodes can be fenced without quorum"),
+ N_("By default, an inquorate node can not fence Pacemaker Remote nodes "
+ "that are part of its partition as long as the cluster thinks they "
+ "can be restarted. If true, inquorate nodes will be able to fence "
+ "remote nodes regardless."),
+ },
{
PCMK_OPT_STONITH_ENABLED, NULL, PCMK_VALUE_BOOLEAN, NULL,
PCMK_VALUE_TRUE, pcmk__valid_boolean,
diff --git a/lib/pengine/unpack.c b/lib/pengine/unpack.c
index 83ecb2d838..2141fca6d8 100644
--- a/lib/pengine/unpack.c
+++ b/lib/pengine/unpack.c
@@ -423,6 +423,14 @@ unpack_config(xmlNode *config, pcmk_scheduler_t *scheduler)
pcmk__readable_interval(scheduler->priv->node_pending_ms));
}
+ set_config_flag(scheduler, PCMK_OPT_FENCE_REMOTE_WITHOUT_QUORUM,
+ pcmk__sched_fence_remote_no_quorum);
+ if (pcmk_is_set(scheduler->flags, pcmk__sched_fence_remote_no_quorum)) {
+ crm_trace("Pacemaker Remote nodes may be fenced without quorum");
+ } else {
+ crm_trace("Pacemaker Remote nodes require quorum to be fenced");
+ }
+
return TRUE;
}
diff --git a/lib/pengine/utils.c b/lib/pengine/utils.c
index 1822acaa54..664b91994e 100644
--- a/lib/pengine/utils.c
+++ b/lib/pengine/utils.c
@@ -70,7 +70,8 @@ pe_can_fence(const pcmk_scheduler_t *scheduler, const pcmk_node_t *node)
* node, not when they are actually started (see remote_connection_assigned)
* so the above test by itself isn't good enough.
*/
- if (pcmk__is_pacemaker_remote_node(node)) {
+ if (pcmk__is_pacemaker_remote_node(node)
+ && !pcmk_is_set(scheduler->flags, pcmk__sched_fence_remote_no_quorum)) {
/* If we're on a system without quorum, it's entirely possible that
* the remote resource was automatically moved to a node on the
* partition with quorum. We can't tell that from this node - the
--
2.31.1
From 168f0df263f739dc1e558b97aae6b49d5b7aa2c2 Mon Sep 17 00:00:00 2001
From: Chris Lumens <clumens@redhat.com>
Date: Wed, 18 Jun 2025 08:41:18 -0400
Subject: [PATCH] Feature: libcrmcommon: bump feature set to 3.20.1
...for Pacemaker Remote node fencing changes.
---
include/crm/crm.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/crm/crm.h b/include/crm/crm.h
index 4d70c7d278..b8a213cb4d 100644
--- a/include/crm/crm.h
+++ b/include/crm/crm.h
@@ -1,5 +1,5 @@
/*
- * Copyright 2004-2024 the Pacemaker project contributors
+ * Copyright 2004-2025 the Pacemaker project contributors
*
* The version control history for this file may have further details.
*
@@ -63,7 +63,7 @@ extern "C" {
* >=3.2.0: DC supports PCMK_EXEC_INVALID and PCMK_EXEC_NOT_CONNECTED
* >=3.19.0: DC supports PCMK__CIB_REQUEST_COMMIT_TRANSACT
*/
-#define CRM_FEATURE_SET "3.20.0"
+#define CRM_FEATURE_SET "3.20.1"
/* Pacemaker's CPG protocols use fixed-width binary fields for the sender and
* recipient of a CPG message. This imposes an arbitrary limit on cluster node
--
2.31.1

1262
003-transient_attrs.patch Normal file
View File

File diff suppressed because it is too large Load Diff

22
gating.yaml
View File

@ -1,22 +0,0 @@
--- !Policy
product_versions:
- fedora-*
decision_context: bodhi_update_push_testing
subject_type: koji_build
rules:
- !PassingTestCaseRule {test_case_name: fedora-ci.koji-build.tier0.functional}
--- !Policy
product_versions:
- fedora-*
decision_context: bodhi_update_push_stable
subject_type: koji_build
rules:
- !PassingTestCaseRule {test_case_name: fedora-ci.koji-build.tier0.functional}
--- !Policy
product_versions:
- rhel-*
decision_context: osci_compose_gate
rules:
- !PassingTestCaseRule {test_case_name: osci.brew-build.tier0.functional}

55
pacemaker.spec
View File

@ -1,5 +1,5 @@
#
# Copyright 2008-2024 the Pacemaker project contributors
# Copyright 2008-2026 the Pacemaker project contributors
#
# The version control history for this file may have further details.
#
@ -27,7 +27,7 @@
## Where bug reports should be submitted
## Leave bug_url undefined to use ClusterLabs default, others define it here
%if 0%{?rhel}
%global bug_url https://issues.redhat.com/
%global bug_url https://github.com/oracle/oracle-linux/
%else
%if 0%{?fedora}
%global bug_url https://bugz.fedoraproject.org/%{name}
@ -40,11 +40,11 @@
## Upstream pacemaker version, and its package version (specversion
## can be incremented to build packages reliably considered "newer"
## than previously built packages with the same pcmkversion)
%global pcmkversion 3.0.0
%global specversion 5
%global pcmkversion 3.0.1
%global specversion 3
## Upstream commit (full commit ID, abbreviated commit ID, or tag) to build
%global commit d8340737c46ccb265bd82c5493b58e9c14ba67e5
%global commit 9a5e54bae85847c4bb6ed7c7fb06103ebebbc64a
## Since git v2.11, the extent of abbreviation is autoscaled by default
## (used to be constant of 7), so we need to convey it for non-tags, too.
@ -184,7 +184,7 @@
Name: pacemaker
Summary: Scalable High-Availability cluster resource manager
Version: %{pcmkversion}
Release: %{pcmk_release}.1%{?dist}
Release: %{pcmk_release}.1.0.1%{?dist}
License: GPL-2.0-or-later AND LGPL-2.1-or-later
Url: https://www.clusterlabs.org/
@ -199,8 +199,9 @@ Url: https://www.clusterlabs.org/
Source0: https://codeload.github.com/%{github_owner}/%{name}/tar.gz/%{archive_github_url}
Source1: pacemaker.sysusers
# upstream commits
Patch001: 001-reset-error-warning-flags.patch
Patch002: 002-remote-fencing.patch
Patch001: 001-econnrefused.patch
Patch002: 002-corosync.patch
Patch003: 003-transient_attrs.patch
Requires: resource-agents
Requires: %{pkgname_pcmk_libs}%{?_isa} = %{version}-%{release}
@ -212,10 +213,10 @@ Requires: %{python_name}-%{name} = %{version}-%{release}
%{?systemd_requires}
%if %{defined centos}
ExclusiveArch: aarch64 i686 ppc64le s390x x86_64 %{arm}
ExclusiveArch: aarch64 i686 ppc64le s390x x86_64 %{arm} riscv64
%else
%if 0%{?rhel}
ExclusiveArch: aarch64 i686 ppc64le s390x x86_64
ExclusiveArch: aarch64 i686 ppc64le s390x x86_64 riscv64
%endif
%endif
@ -274,7 +275,6 @@ BuildRequires: %{pkgname_glue_libs}-devel
%endif
%if %{with doc}
BuildRequires: asciidoc
BuildRequires: %{python_name}-sphinx
%endif
@ -500,7 +500,7 @@ popd
%check
make %{_smp_mflags} check
{ cts/cts-scheduler --run load-stopped-loop \
&& cts/cts-cli \
&& cts/cts-cli -V \
&& touch .CHECKED
} 2>&1 | sed 's/[fF]ail/faiil/g' # prevent false positives in rpmlint
[ -f .CHECKED ] && rm -f -- .CHECKED
@ -793,9 +793,34 @@ exit 0
%{_datadir}/pkgconfig/pacemaker-schemas.pc
%changelog
* Fri Aug 08 2025 Darren Archibald <darren.archibald@oracle.com> - 3.0.0-5.1
- Add option for controlling remote node fencing behavior
- Resolves: RHEL-101072
* Tue Feb 24 2026 EL Errata <el-errata_ww@oracle.com> - 3.0.1-3.1.0.1
- Replace bug url [Orabug: 34202300]
- Upstream reference in pacemaker crm_report binary [Orabug: 32825154]
* Mon Jan 19 2026 Chris Lumens <clumens@redhat.com> - 3.0.1-3.1
- Fix a race condition between daemons when erasing transient attrs
- Resolves: RHEL-135091
* Wed Aug 13 2025 Reid Wahl <nwahl@redhat.com> - 3.0.1-3
- CTS launches Corosync using systemd if available.
- Resolves: RHEL-110075
* Mon Aug 11 2025 Chris Lumens <clumens@redhat.com> - 3.0.1-2
- Do not retry on ECONNREFUSED in command line tools.
- Resolves: RHEL-106594
* Tue Jun 24 2025 Chris Lumens <clumens@redhat.com> - 3.0.1-1
- Rebase on upstream 3.0.1-rc1
- Use dbus to detect completion of systemd resource start/stop actions
- Add an option for controlling remote node fencing behavior
- Split large IPC messages into multiple smaller ones
- Related: RHEL-86085
- Resolves: RHEL-71181
- Resolves: RHEL-86146
- Resolves: RHEL-86144
* Wed Apr 02 2025 Kashyap Chamarthy <kchamart@redhat.com> - 3.0.0-6
- Add riscv64 into ExclusiveArch (thanks, Zhengyu He)
* Fri Jan 10 2025 Chris Lumens <clumens@redhat.com> - 3.0.0-5
- Rebase on upstream 3.0.0 final release

2
sources
View File

@ -1 +1 @@
SHA512 (pacemaker-d8340737c.tar.gz) = d91c7aa0cd5c607061e43b9b9403cfa806b86eb2730187e701a40c2b245ce8fbf34361af7a5ac9a4985b34f0dbdc6436815dcba5b6b177a7d058692599bd46ec
SHA512 (pacemaker-9a5e54bae.tar.gz) = 7c90f7cb985933ba3e0254118bab5c2af050e61c22ab683255c06282df196dcca439ecdc016e22fa7751a4744092abd6801451babfb8f4d03d4d67c1fee56ed9

4
tests/inventory
View File

@ -1,4 +0,0 @@
#!/bin/bash
export TEST_DOCKER_EXTRA_ARGS="--network host"
exec merge-standard-inventory "$@"

14
tests/tests.yml
View File

@ -1,14 +0,0 @@
---
- hosts: localhost
roles:
- role: standard-test-basic
tags:
- classic
- container
tests:
- cts-regression:
dir: .
run: /usr/share/pacemaker/tests/cts-regression cli scheduler fencing
required_packages:
- pacemaker
- pacemaker-cts