[ClusterLabs] Request for comments: Deprecating five cluster properties

[Reid Wahl]

On Fri, Sep 26, 2025 at 12:26 PM Vladislav Bogdanov
<bubble at hoster-ok.com> wrote:
>
> I would vote to leave 'stop-all-resources' available. Decade(s) ago, when I've been creating projects with pacemaker, it was very much usefull. Cluster can have some resources disabled with Target-Role for a reason (f.e. ongoing development). That resources would start after disable/enable cycle by pcs/crmsh, potentionally leading to a fencing cycle. After all, it is just much simpler to set a cluster property than doing all that black magic with constraints (which you may have hundreds of them and you can not recall how you named that one).

Thank you for responding!

I felt that it wasn't especially useful since there are alternatives
that are fairly simple -- in particular, placing all nodes in standby.

I could see limited use for it... suppose one node is already in
standby and we want to temporarily stop all resources and then allow
them to run again later. Putting all nodes in standby and then taking
all nodes out of standby doesn't return us to the original state. The
user would have to track which nodes were already in standby and
ensure that those nodes remain in standby.

And I suppose this is analogous to the situation with the
maintenance-mode cluster property, the node maintenance attribute, and
the resource maintenance meta-attribute.

So yes, we can keep this property.

>
> On September 26, 2025 20:44:22 Reid Wahl <nwahl at redhat.com> wrote:
>
>> 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/
>
>


-- 
Regards,

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