-
Notifications
You must be signed in to change notification settings - Fork 365
Fix: Check for watchdog-based self-fencing device only if "fencing-watchdog-timeout" is enabled #4146
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Fix: Check for watchdog-based self-fencing device only if "fencing-watchdog-timeout" is enabled #4146
Changes from all commits
39b828f
a69067b
5ec2059
cf58cca
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -995,13 +995,19 @@ void | |
| controld_validate_fencing_watchdog_timeout(const char *value) | ||
| { | ||
| const char *our_nodename = controld_globals.cluster->priv->node_name; | ||
| long long timeout_ms = 0; | ||
|
|
||
| timeout_ms = pcmk__parse_fencing_watchdog_timeout(value); | ||
| if (timeout_ms == 0) { | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Now, if the timeout fails to parse, Previously, if the timeout failed to parse, we would continue to the next block and call Wouldn't we want to call Edit: Previously, I guess we would have passed This doesn't look like a meaningful change in behavior after all. The only difference is that now we will no longer call Edit:
Actually, the "previous" behavior was only introduced by your first commit lol ;) So it really doesn't seem to matter.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. After all, it's about what behavior we should expect from a misconfiguration. And it should be consistent wherever it's parsed. |
||
| return; | ||
| } | ||
|
|
||
| // Validate only if the timeout will be used | ||
| if ((fencer_api != NULL) && (fencer_api->state != stonith_disconnected) | ||
| && stonith__watchdog_fencing_enabled_for_node_api(fencer_api, | ||
| our_nodename)) { | ||
|
|
||
| pcmk__valid_fencing_watchdog_timeout(value); | ||
| pcmk__valid_fencing_watchdog_timeout(timeout_ms); | ||
| } | ||
| } | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1029,13 +1029,15 @@ lrmd__validate_remote_settings(lrmd_t *lrmd, GHashTable *hash) | |
| const char *value; | ||
| lrmd_private_t *native = lrmd->lrmd_private; | ||
| xmlNode *data = pcmk__xe_create(NULL, PCMK__XA_LRMD_OP); | ||
| long long timeout_ms = 0; | ||
|
|
||
| pcmk__xe_set(data, PCMK__XA_LRMD_ORIGIN, __func__); | ||
|
|
||
| value = pcmk__cluster_option(hash, PCMK_OPT_FENCING_WATCHDOG_TIMEOUT); | ||
| if ((value) && | ||
| timeout_ms = pcmk__parse_fencing_watchdog_timeout(value); | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Previously, if we parsed a negative value, we would set it directly as Now, if we parse a negative value, I think that's fine. The receiving end (in |
||
| if ((timeout_ms != 0) && | ||
| (stonith__watchdog_fencing_enabled_for_node(native->remote_nodename))) { | ||
| pcmk__xe_set(data, PCMK__XA_LRMD_WATCHDOG, value); | ||
| pcmk__xe_set_ll(data, PCMK__XA_LRMD_WATCHDOG, timeout_ms); | ||
| } | ||
|
|
||
| rc = lrmd_send_command(lrmd, LRMD_OP_CHECK, data, NULL, 0, 0, | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the regression cause only misleading log messages, or does it cause real misbehavior?
IMO, it seems that the log message should be at debug level instead of notice level anyway. And that would avoid the whole "confusing log" issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It mainly causes the misleading messages. But of course the checks with stonith__watchdog_fencing_enabled_for_node_api(), which cost IPCs, are totally meaningless when watchdog-based fencing is not even configured/enabled.
About the logging level of the message, there are some comments around the code about some "race". So I'm not sure what "-ENODEV" is supposed to indicate if "fencing-watchdog-timeout" is actually enabled.