[ClusterLabs] [EXT] Request for comments: Deprecating five cluster properties

[Reid Wahl]

On Fri, Nov 7, 2025 at 5:24 AM Windl, Ulrich <u.windl at ukr.de> wrote:
>
> Hi!
>
> I'm late on this, but does pacemaker have a command to stop the whole cluster cleanly (without moving resources, for example)? HP Sevice Guard had (AFAIR) a cmhaltcl (halt cluster) command that would cleanly stop the cluster software on all nodes WITHOUT changing the configuration of any resource, so that they would all start normally when starting the cluster again.
> To me this is much more elegant compared to changing all the resources to stopped via a CIB change.

Nothing comes to mind.

Most things in Pacemaker operate either via a configuration change in
the CIB, or on one node at a time (like stopping Pacemaker daemons).
There may be some slight exceptions like attrd updates, which still
normally get written to the CIB.

You can set the shutdown-lock cluster property to true:
"The default of false allows active resources to be recovered
elsewhere when their node is cleanly shut down, which is what the vast
majority of users will want. However, some users prefer to make
resources highly available only for failures, with no recovery for
clean shutdowns. If this option is true, resources active on a node
when it is cleanly shut down are kept “locked” to that node (not
allowed to run elsewhere) until they start again on that node after it
rejoins (or for at most shutdown-lock-limit, if set). Stonith
resources and Pacemaker Remote connections are never locked. Clone and
bundle instances and the promoted role of promotable clones are
currently never locked, though support could be added in a future
release."

That still involves a configuration change, but only once.

Higher-level tools like pcs have commands similar to cmhaltcl. For
example, `pcs cluster stop --all` stops the cluster (and by default,
all resources) on all nodes. But AFAICT, it does this independently
(but in parallel) on each node. So it would be sort of like connecting
to each node simultaneously with SSH and running `systemctl stop
pacemaker && systemctl stop corosync`.

>
> Kind regards,
> Ulrich Windl
>
> > -----Original Message-----
> > From: Users <users-bounces at clusterlabs.org> On Behalf Of Reid Wahl
> > Sent: Friday, September 26, 2025 8:44 PM
> > To: Cluster Labs - All topics related to open-source clustering welcomed
> > <users at clusterlabs.org>
> > Subject: [EXT] [ClusterLabs] Request for comments: Deprecating five cluster
> > properties
> >
> > We're considering deprecating, and eventually dropping, five cluster
> > properties. Does anyone object? If you find any of these useful, I'd
> > love to hear how you're using them and why.
> >
> > cluster-ipc-limit:
> > This actually has no effect since ae3b5dc. Prior to that, it affected
> > only pacemaker-based.
> >
> > --
> >
> > enable-startup-probes:
> > Setting this property to false is dangerous in that it prevents
> > Pacemaker from gaining an accurate view of resource state, without
> > preventing other actions as (for example) maintenance mode would do.
> >
> > You can disable probes using a location constraint rule with
> > resource-discovery=never instead.
> >
> > This option was introduced by commit b20fd76, and the expressed
> > motivation was that the "calculation [of startup probes] is a major
> > bottleneck for very large clusters." I doubt that's a major concern on
> > modern hardware, and even if it is, Pacemaker still should have a
> > correct view of resource state.
> >
> > --
> >
> > stop-removed-resources (formerly stop-orphaned-resources):
> > This property was introduced in 2006 by commit ea1359b, with no
> > motivation or use case given. It defaults to true. It seems like a bad
> > idea for Pacemaker to continue running resources that are not part of
> > its configuration.
> >
> > --
> >
> > cancel-removed-actions (formerly stop-removed-actions and
> > stop-orphaned-actions):
> > This property was introduced in 2006 by commit ea1359b, with no
> > motivation or use case given. It defaults to true. It seems like a bad
> > idea for Pacemaker to continue running actions that are not part of
> > its configuration.
> >
> > --
> >
> > stop-all-resources:
> > This property was introduced in 2008 by commit 0d6945b, with no
> > motivation or use case given.
> >
> > On rare occasions, I have found it convenient for troubleshooting
> > purposes. However, it can be achieved by a location constraint with
> > rsc-pattern=".*" and a rule matching all nodes. It can also be
> > achieved by placing all nodes in standby mode. It seems unlikely to be
> > very useful to anyone besides developers.
> >
> > Dropping this property would simplify output messages and the set of
> > overlapping, possibly conflicting options that control where resources
> > are allowed to run. (Precedence has to be determined when options
> > conflict, and such a choice will always be somewhat arbitrary.)
> >
> > If you're using pcs, you can stop all resources by putting all nodes
> > in standby: `pcs node standby --all`. That's how I do it in practice.
> > I presume crmsh has a similar functionality.
> >
> > --
> > Regards,
> >
> > Reid Wahl (He/Him)
> > Senior Software Engineer, Red Hat
> > RHEL High Availability - Pacemaker
> >
> > _______________________________________________
> > Manage your subscription:
> > https://lists.clusterlabs.org/mailman/listinfo/users
> >
> > ClusterLabs home: https://www.clusterlabs.org/
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users
>
> ClusterLabs home: https://www.clusterlabs.org/
>


-- 
Regards,

Reid Wahl (He/Him)
Senior Software Engineer, Red Hat
RHEL High Availability - Pacemaker