This repository has been archived by the owner on May 3, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 142
CORTX-29713: m0_conf_pver_status() now returns CRITICAL if max failures reached at any level #1571
Merged
Conversation
This file contains 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
…es reached at any level When the allowance was set to less than K at any level, and that many numbers of failures was reached, then bytecount had become critical, but it was still marked as degraded according to old logic as the failures were still less than K. ex: in a 3 node cluster with SNS 4+2+0, we support at max 1 node failure. So when a node failed, data should've become critical, but with old logic, it was marked as degraded, as number of failures was 1 which is < K. Updated the logic to check if failures at any level has reached it's max or not. If it does then pool version is marked as CRITICAL even if failures < K. Signed-off-by: Abhishek Saha <abhishek.saha@seagate.com>
AbhishekSahaSeagate
requested review from
mehjoshi,
madhavemuri,
nikitadanilov,
yeshpal-jain-seagate,
huanghua78,
andriytk,
siningwuseagate,
vidyadhar-pinglikar,
shashank-parulekar,
nkommuri,
sg-shankar,
ivan-alekhin and
sergey-shilov
as code owners
March 29, 2022 10:15
madhavemuri
approved these changes
Mar 30, 2022
mehjoshi
reviewed
Mar 30, 2022
Now instead of returning whether any level has reached max failures or not, it returns an integer marking MAX_FAILURE_NOT_REACHED, MAX_FAILURE_REACHED, MAX_FAILURE_EXCEEDED. This further helps in more accurate marking of DEGRADED, CRITICAL and DAMAGED states. Changed the logic of m0_conf_pver_status() accordingly. Signed-off-by: Abhishek Saha <abhishek.saha@seagate.com>
mehjoshi
reviewed
Apr 1, 2022
@madhavemuri, @yeshpal-jain-seagate, The code was updated after Madhav's last review and approval. |
madhavemuri
approved these changes
Apr 5, 2022
Signed-off-by: Abhishek Saha <abhishek.saha@seagate.com>
yeshpal-jain-seagate
approved these changes
Apr 5, 2022
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
When the allowance was set to less than K at any level, and that many numbers of failures
was reached, then bytecount had become critical, but it was still marked as degraded
according to old logic as the failures were still less than K.
ex: in a 3 node cluster with SNS 4+2+0, we support at max 1 node failure.
So when a node failed, data should've become critical, but with old logic,
it was marked as degraded, as number of failures was 1 which is < K.
Updated the logic to check if failures at any level has reached it's max or not.
If it does then pool version is marked as CRITICAL even if failures < K.
Signed-off-by: Abhishek Saha abhishek.saha@seagate.com
Problem Statement
Design
Coding
Checklist for Author
Testing
Checklist for Author
Impact Analysis
Checklist for Author/Reviewer/GateKeeper
Review Checklist
Checklist for Author
Documentation
Checklist for Author