Let's just drop auto-calculation and use 0 for negative or invalid values.

Bah. It's not in the product docs but it is in the design guidance article.

In T749#13824, @kgaillot wrote:

Revisiting this, we should check whether negative stonith-watchdog-timeout is either used by pcs or documented anywhere downstream. If not, just drop the auto-calculation feature and require nonnegative values.

Revisiting this, we should check whether negative stonith-watchdog-timeout is either used by pcs or documented anywhere downstream. If not, just drop the auto-calculation feature and require nonnegative values.

I guess there are more dimension to this problem:

This would be worth backporting to 2.1 if easy

Currently lrmd_remote_client_msg() calls pcmk__read_remote_message(), which loops over read_available_remote_data() up to the timeout.

In T855#13286, @clumens wrote:

My first thought here is to start by converting pcmk__remote_ready to be an async function that checks the remote to see if it's ready once and sends a result up to the mainloop. However, one caller of this function is lrmd_poll, which we do not use anywhere but I assume is public API. Do we need to continue keeping it (and lrmd_dispatch) around? If so, we might need sync and async versions of this function.

My first thought here is to start by converting pcmk__remote_ready to be an async function that checks the remote to see if it's ready once and sends a result up to the mainloop. However, one caller of this function is lrmd_poll, which we do not use anywhere but I assume is public API. Do we need to continue keeping it (and lrmd_dispatch) around? If so, we might need sync and async versions of this function.

In T745#12714, @kgaillot wrote:

I've already got something ready to go

I've already got something ready to go

hope ya don't mind if I grab this one

Closed via cb298b9e. None of the commits from https://github.com/ClusterLabs/pacemaker/pull/3539 were properly linked here, despite their commit messages having the relevant phrases.

I suspect the use case for this feature was being able to set an explicit value in one block of meta-attributes, then have another rule-based block of attributes that resets the value to the default. Simply omitting the meta-attribute from the rule-based block wouldn't cause the explicit value to be removed.