Feature: any delays from pcmk_delay_base/max are added to priority-fencing-delay#2027
Merged
kgaillot merged 6 commits intoApr 3, 2020
Merged
Conversation
|
Looks good to me. Why would the priority delay need to be twice the other? I would think anything greater would work. @wenningerk , thoughts? |
Contributor
Don't see a reason why it would have to be double either. |
Member
Author
|
Define "significantly" :-) Users would ask the same. If users set a relatively big value of pcmk_delay_base/max, it means they expect relatively big "difference" in terms of delay so that it's safe enough to prevent double-fencing. Considering the corner cases we are trying to cover here, there should be corresponding "difference" gets reflected by |
Contributor
|
I think twice is good as a simple recommendation. It just shouldn't read as if there was a |
gao-yan
force-pushed
the
combine-priority-fencing-delay
branch
2 times, most recently
from
48cedc5 to
347d105
Compare
Member
Author
|
Now it's "This delay should be significantly greater than, safely twice, the maximum |
Contributor
|
Content-wise I'm fine with it. Language details I leave for the native-speakers to comment on ;-) |
Member
Author
|
Ok. @kgaillot must have better ideas on the phrasing :-) |
|
Works for me. @wenningerk , any comments on overall PR? |
Contributor
|
Looking good to me.
|
Member
Author
You mean you prefer the word "added" rather than "combined" to be used in the doc/metadata, code comments and commit descriptions? Sure, if you think that's better :-)
It's what it exactly does invoking fence_with_delay() with "-1". Or do you mean "-1" for priority-fencing-delay should disable all delays including pcmk_delay_base/max? Is it a condition that an option so-called "priority-fencing-delay" should cover? |
Member
Author
Or do you mean the descriptions about the meaning of value "-1" for the |
Contributor
Yes - directly naming the operation done ...
Scratch my comment about '-1' it is fine as it is. |
…bled This commit also documents the upcoming new behavior as discussed from: ClusterLabs#2012 Any static/random delays that are introduced by `pcmk_delay_base/max` configured for the corresponding fencing resources will be added to this delay. This delay should be significantly greater than, safely twice, the maximum `pcmk_delay_base/max`. By default, priority fencing delay is disabled.
… have equal priority In any cases, priority-fencing-delay won't take precedence over any configured pcmk_delay_base/max.
…uested fencing delay Requested fencing delay doesn't take precedence over any configured pcmk_delay_base/max. A delay value -1 now means disable also any static/random fencing delays from pcmk_delay_base/max. It's not used by any consumers for now.
This commit also documents the current behavior in the help: - Any static/random delays from pcmk_delay_base/max will be added to requested fencing delay. - A delay value -1 now means disable also any static/random fencing delays from pcmk_delay_base/max.
…y_base is added This commit also updates log patterns for the log changes.
gao-yan
force-pushed
the
combine-priority-fencing-delay
branch
from
347d105 to
6ab6d38
Compare
gao-yan
changed the title
nrwahl2
added a commit
to nrwahl2/pacemaker
that referenced
this pull request
Mar 19, 2025
To replace crm_element_value_int(). Note that, like the other recently added getter functions, this leaves dest unchanged on error. crm_element_value_int() set dest to -1. This should indirectly improve some of the callers, which were not error-checking crm_element_value_int()'s return code and simply assumed the value was valid and not -1. And IMO, it's better not to log errors or warnings within the getter function as crm_element_value_int() was doing. The caller has more context and can log errors or warnings if appropriate. Sometimes, a parse failure may be expected as a legitimate possibility. The one case I found questionable was the getting of PCMK__XA_ST_DELAY in create_remote_stonith_op(). If that value is set to -1, then all delays are disabled. crm_element_value_int() sets the value to -1 upon a parse error, and this function was not doing any error checking before now. So I wondered if we were relying on the parse error defaulting to -1. However, I don't think it's a problem. It looks like that attribute is only ever getting set by crm_xml_add_int() -- so even if it's set based on user input, it's set to a valid integer. The -1 value seems to be intended only for when it's set explicitly to -1. We simply haven't error-checked the parsing before now. See commit a0cbd52 and associated commits in PR ClusterLabs#2027. Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
nrwahl2
added a commit
to nrwahl2/pacemaker
that referenced
this pull request
Mar 20, 2025
To replace crm_element_value_int(). Note that, like the other recently added getter functions, this leaves dest unchanged on error. crm_element_value_int() set dest to -1. This should indirectly improve some of the callers, which were not error-checking crm_element_value_int()'s return code and simply assumed the value was valid and not -1. And IMO, it's better not to log errors or warnings within the getter function as crm_element_value_int() was doing. The caller has more context and can log errors or warnings if appropriate. Sometimes, a parse failure may be expected as a legitimate possibility. The one case I found questionable was the getting of PCMK__XA_ST_DELAY in create_remote_stonith_op(). If that value is set to -1, then all delays are disabled. crm_element_value_int() sets the value to -1 upon a parse error, and this function was not doing any error checking before now. So I wondered if we were relying on the parse error defaulting to -1. However, I don't think it's a problem. It looks like that attribute is only ever getting set by crm_xml_add_int() -- so even if it's set based on user input, it's set to a valid integer. The -1 value seems to be intended only for when it's set explicitly to -1. We simply haven't error-checked the parsing before now. See commit a0cbd52 and associated commits in PR ClusterLabs#2027. Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
nrwahl2
added a commit
to nrwahl2/pacemaker
that referenced
this pull request
Mar 20, 2025
To replace crm_element_value_int(). Note that, like the other recently added getter functions, this leaves dest unchanged on error. crm_element_value_int() set dest to -1. This should indirectly improve some of the callers, which were not error-checking crm_element_value_int()'s return code and simply assumed the value was valid and not -1. And IMO, it's better not to log errors or warnings within the getter function as crm_element_value_int() was doing. The caller has more context and can log errors or warnings if appropriate. Sometimes, a parse failure may be expected as a legitimate possibility. The one case I found questionable was the getting of PCMK__XA_ST_DELAY in create_remote_stonith_op(). If that value is set to -1, then all delays are disabled. crm_element_value_int() sets the value to -1 upon a parse error, and this function was not doing any error checking before now. So I wondered if we were relying on the parse error defaulting to -1. However, I don't think it's a problem. It looks like that attribute is only ever getting set by crm_xml_add_int() -- so even if it's set based on user input, it's set to a valid integer. The -1 value seems to be intended only for when it's set explicitly to -1. We simply haven't error-checked the parsing before now. See commit a0cbd52 and associated commits in PR ClusterLabs#2027. Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
nrwahl2
added a commit
to nrwahl2/pacemaker
that referenced
this pull request
Mar 21, 2025
To replace crm_element_value_int(). Note that, like the other recently added getter functions, this leaves dest unchanged on error. crm_element_value_int() set dest to -1. This should indirectly improve some of the callers, which were not error-checking crm_element_value_int()'s return code and simply assumed the value was valid and not -1. And IMO, it's better not to log errors or warnings within the getter function as crm_element_value_int() was doing. The caller has more context and can log errors or warnings if appropriate. Sometimes, a parse failure may be expected as a legitimate possibility. The one case I found questionable was the getting of PCMK__XA_ST_DELAY in create_remote_stonith_op(). If that value is set to -1, then all delays are disabled. crm_element_value_int() sets the value to -1 upon a parse error, and this function was not doing any error checking before now. So I wondered if we were relying on the parse error defaulting to -1. However, I don't think it's a problem. It looks like that attribute is only ever getting set by crm_xml_add_int() -- so even if it's set based on user input, it's set to a valid integer. The -1 value seems to be intended only for when it's set explicitly to -1. We simply haven't error-checked the parsing before now. See commit a0cbd52 and associated commits in PR ClusterLabs#2027. Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
nrwahl2
added a commit
to nrwahl2/pacemaker
that referenced
this pull request
Mar 21, 2025
To replace crm_element_value_int(). Note that, like the other recently added getter functions, this leaves dest unchanged on error. crm_element_value_int() set dest to -1. This should indirectly improve some of the callers, which were not error-checking crm_element_value_int()'s return code and simply assumed the value was valid and not -1. And IMO, it's better not to log errors or warnings within the getter function as crm_element_value_int() was doing. The caller has more context and can log errors or warnings if appropriate. Sometimes, a parse failure may be expected as a legitimate possibility. The one case I found questionable was the getting of PCMK__XA_ST_DELAY in create_remote_stonith_op(). If that value is set to -1, then all delays are disabled. crm_element_value_int() sets the value to -1 upon a parse error, and this function was not doing any error checking before now. So I wondered if we were relying on the parse error defaulting to -1. However, I don't think it's a problem. It looks like that attribute is only ever getting set by crm_xml_add_int() -- so even if it's set based on user input, it's set to a valid integer. The -1 value seems to be intended only for when it's set explicitly to -1. We simply haven't error-checked the parsing before now. See commit a0cbd52 and associated commits in PR ClusterLabs#2027. Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
nrwahl2
added a commit
to nrwahl2/pacemaker
that referenced
this pull request
Mar 21, 2025
To replace crm_element_value_int(). Note that, like the other recently added getter functions, this leaves dest unchanged on error. crm_element_value_int() set dest to -1. This should indirectly improve some of the callers, which were not error-checking crm_element_value_int()'s return code and simply assumed the value was valid and not -1. And IMO, it's better not to log errors or warnings within the getter function as crm_element_value_int() was doing. The caller has more context and can log errors or warnings if appropriate. Sometimes, a parse failure may be expected as a legitimate possibility. The one case I found questionable was the getting of PCMK__XA_ST_DELAY in create_remote_stonith_op(). If that value is set to -1, then all delays are disabled. crm_element_value_int() sets the value to -1 upon a parse error, and this function was not doing any error checking before now. So I wondered if we were relying on the parse error defaulting to -1. However, I don't think it's a problem. It looks like that attribute is only ever getting set by crm_xml_add_int() -- so even if it's set based on user input, it's set to a valid integer. The -1 value seems to be intended only for when it's set explicitly to -1. We simply haven't error-checked the parsing before now. See commit a0cbd52 and associated commits in PR ClusterLabs#2027. Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
nrwahl2
added a commit
to nrwahl2/pacemaker
that referenced
this pull request
Mar 24, 2025
To replace crm_element_value_int(). Note that, like the other recently added getter functions, this leaves dest unchanged on error. crm_element_value_int() set dest to -1. This should indirectly improve some of the callers, which were not error-checking crm_element_value_int()'s return code and simply assumed the value was valid and not -1. And IMO, it's better not to log errors or warnings within the getter function as crm_element_value_int() was doing. The caller has more context and can log errors or warnings if appropriate. Sometimes, a parse failure may be expected as a legitimate possibility. The one case I found questionable was the getting of PCMK__XA_ST_DELAY in create_remote_stonith_op(). If that value is set to -1, then all delays are disabled. crm_element_value_int() sets the value to -1 upon a parse error, and this function was not doing any error checking before now. So I wondered if we were relying on the parse error defaulting to -1. However, I don't think it's a problem. It looks like that attribute is only ever getting set by crm_xml_add_int() -- so even if it's set based on user input, it's set to a valid integer. The -1 value seems to be intended only for when it's set explicitly to -1. We simply haven't error-checked the parsing before now. See commit a0cbd52 and associated commits in PR ClusterLabs#2027. Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
nrwahl2
added a commit
to nrwahl2/pacemaker
that referenced
this pull request
Mar 25, 2025
To replace crm_element_value_int(). Note that, like the other recently added getter functions, this leaves dest unchanged on error. crm_element_value_int() set dest to -1. This should indirectly improve some of the callers, which were not error-checking crm_element_value_int()'s return code and simply assumed the value was valid and not -1. And IMO, it's better not to log errors or warnings within the getter function as crm_element_value_int() was doing. The caller has more context and can log errors or warnings if appropriate. Sometimes, a parse failure may be expected as a legitimate possibility. The one case I found questionable was the getting of PCMK__XA_ST_DELAY in create_remote_stonith_op(). If that value is set to -1, then all delays are disabled. crm_element_value_int() sets the value to -1 upon a parse error, and this function was not doing any error checking before now. So I wondered if we were relying on the parse error defaulting to -1. However, I don't think it's a problem. It looks like that attribute is only ever getting set by crm_xml_add_int() -- so even if it's set based on user input, it's set to a valid integer. The -1 value seems to be intended only for when it's set explicitly to -1. We simply haven't error-checked the parsing before now. See commit a0cbd52 and associated commits in PR ClusterLabs#2027. Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
nrwahl2
added a commit
to nrwahl2/pacemaker
that referenced
this pull request
Mar 27, 2025
To replace crm_element_value_int(). Note that, like the other recently added getter functions, this leaves dest unchanged on error. crm_element_value_int() set dest to -1. This should indirectly improve some of the callers, which were not error-checking crm_element_value_int()'s return code and simply assumed the value was valid and not -1. And IMO, it's better not to log errors or warnings within the getter function as crm_element_value_int() was doing. The caller has more context and can log errors or warnings if appropriate. Sometimes, a parse failure may be expected as a legitimate possibility. The one case I found questionable was the getting of PCMK__XA_ST_DELAY in create_remote_stonith_op(). If that value is set to -1, then all delays are disabled. crm_element_value_int() sets the value to -1 upon a parse error, and this function was not doing any error checking before now. So I wondered if we were relying on the parse error defaulting to -1. However, I don't think it's a problem. It looks like that attribute is only ever getting set by crm_xml_add_int() -- so even if it's set based on user input, it's set to a valid integer. The -1 value seems to be intended only for when it's set explicitly to -1. We simply haven't error-checked the parsing before now. See commit a0cbd52 and associated commits in PR ClusterLabs#2027. Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
nrwahl2
added a commit
to nrwahl2/pacemaker
that referenced
this pull request
Jul 3, 2025
To replace crm_element_value_int(). Note that, like the other recently added getter functions, this leaves dest unchanged on error. crm_element_value_int() set dest to -1. This should indirectly improve some of the callers, which were not error-checking crm_element_value_int()'s return code and simply assumed the value was valid and not -1. And IMO, it's better not to log errors or warnings within the getter function as crm_element_value_int() was doing. The caller has more context and can log errors or warnings if appropriate. Sometimes, a parse failure may be expected as a legitimate possibility. The one case I found questionable was the getting of PCMK__XA_ST_DELAY in create_remote_stonith_op(). If that value is set to -1, then all delays are disabled. crm_element_value_int() sets the value to -1 upon a parse error, and this function was not doing any error checking before now. So I wondered if we were relying on the parse error defaulting to -1. However, I don't think it's a problem. It looks like that attribute is only ever getting set by crm_xml_add_int() -- so even if it's set based on user input, it's set to a valid integer. The -1 value seems to be intended only for when it's set explicitly to -1. We simply haven't error-checked the parsing before now. See commit a0cbd52 and associated commits in PR ClusterLabs#2027. Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
nrwahl2
added a commit
to nrwahl2/pacemaker
that referenced
this pull request
Jul 23, 2025
To replace crm_element_value_int(). Note that, like the other recently added getter functions, this leaves dest unchanged on error. crm_element_value_int() set dest to -1. This should indirectly improve some of the callers, which were not error-checking crm_element_value_int()'s return code and simply assumed the value was valid and not -1. And IMO, it's better not to log errors or warnings within the getter function as crm_element_value_int() was doing. The caller has more context and can log errors or warnings if appropriate. Sometimes, a parse failure may be expected as a legitimate possibility. The one case I found questionable was the getting of PCMK__XA_ST_DELAY in create_remote_stonith_op(). If that value is set to -1, then all delays are disabled. crm_element_value_int() sets the value to -1 upon a parse error, and this function was not doing any error checking before now. So I wondered if we were relying on the parse error defaulting to -1. However, I don't think it's a problem. It looks like that attribute is only ever getting set by crm_xml_add_int() -- so even if it's set based on user input, it's set to a valid integer. The -1 value seems to be intended only for when it's set explicitly to -1. We simply haven't error-checked the parsing before now. See commit a0cbd52 and associated commits in PR ClusterLabs#2027. Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
nrwahl2
added a commit
to nrwahl2/pacemaker
that referenced
this pull request
Jul 23, 2025
To replace crm_element_value_int(). Note that, like the other recently added getter functions, this leaves dest unchanged on error. crm_element_value_int() set dest to -1. This should indirectly improve some of the callers, which were not error-checking crm_element_value_int()'s return code and simply assumed the value was valid and not -1. And IMO, it's better not to log errors or warnings within the getter function as crm_element_value_int() was doing. The caller has more context and can log errors or warnings if appropriate. Sometimes, a parse failure may be expected as a legitimate possibility. The one case I found questionable was the getting of PCMK__XA_ST_DELAY in create_remote_stonith_op(). If that value is set to -1, then all delays are disabled. crm_element_value_int() sets the value to -1 upon a parse error, and this function was not doing any error checking before now. So I wondered if we were relying on the parse error defaulting to -1. However, I don't think it's a problem. It looks like that attribute is only ever getting set by crm_xml_add_int() -- so even if it's set based on user input, it's set to a valid integer. The -1 value seems to be intended only for when it's set explicitly to -1. We simply haven't error-checked the parsing before now. See commit a0cbd52 and associated commits in PR ClusterLabs#2027. Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
nrwahl2
added a commit
to nrwahl2/pacemaker
that referenced
this pull request
Jul 24, 2025
To replace crm_element_value_int(). Note that, like the other recently added getter functions, this leaves dest unchanged on error. crm_element_value_int() set dest to -1. This should indirectly improve some of the callers, which were not error-checking crm_element_value_int()'s return code and simply assumed the value was valid and not -1. And IMO, it's better not to log errors or warnings within the getter function as crm_element_value_int() was doing. The caller has more context and can log errors or warnings if appropriate. Sometimes, a parse failure may be expected as a legitimate possibility. The one case I found questionable was the getting of PCMK__XA_ST_DELAY in create_remote_stonith_op(). If that value is set to -1, then all delays are disabled. crm_element_value_int() sets the value to -1 upon a parse error, and this function was not doing any error checking before now. So I wondered if we were relying on the parse error defaulting to -1. However, I don't think it's a problem. It looks like that attribute is only ever getting set by crm_xml_add_int() -- so even if it's set based on user input, it's set to a valid integer. The -1 value seems to be intended only for when it's set explicitly to -1. We simply haven't error-checked the parsing before now. See commit a0cbd52 and associated commits in PR ClusterLabs#2027. Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
nrwahl2
added a commit
to nrwahl2/pacemaker
that referenced
this pull request
Aug 6, 2025
To replace crm_element_value_int(). Note that, like the other recently added getter functions, this leaves dest unchanged on error. crm_element_value_int() set dest to -1. This should indirectly improve some of the callers, which were not error-checking crm_element_value_int()'s return code and simply assumed the value was valid and not -1. And IMO, it's better not to log errors or warnings within the getter function as crm_element_value_int() was doing. The caller has more context and can log errors or warnings if appropriate. Sometimes, a parse failure may be expected as a legitimate possibility. The one case I found questionable was the getting of PCMK__XA_ST_DELAY in create_remote_stonith_op(). If that value is set to -1, then all delays are disabled. crm_element_value_int() sets the value to -1 upon a parse error, and this function was not doing any error checking before now. So I wondered if we were relying on the parse error defaulting to -1. However, I don't think it's a problem. It looks like that attribute is only ever getting set by crm_xml_add_int() -- so even if it's set based on user input, it's set to a valid integer. The -1 value seems to be intended only for when it's set explicitly to -1. We simply haven't error-checked the parsing before now. See commit a0cbd52 and associated commits in PR ClusterLabs#2027. Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This introduces the new behavior as discussed from:
#2012
Any static/random delays that are introduced by
pcmk_delay_base/maxconfigured for the corresponding fencing resources will be added to
priority-fencing-delay. This delay should be significantly greater than, safely twice,the maximum
pcmk_delay_base/max. By default, priority fencing delay isdisabled.