Fix network exception handling and fencing flow logic. #254
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
This patch fixes network exception handling and fencing flow logic.
Problems in current code:
1. Hard fencing happens too fast since we waited on number of
attempts <or> grace period, since number of attempts is configured to a
value of "2", grace period was ~20 seconds.
2. VdsManager::isHostInGracePeriod was called periodically from
VdsManager:handleNetworkExeception and from
SsshSoftFencingCommand::checkIfHostBecomeUp which makes the logic
complex in not working as expected
While we have to handle the network exception grace period when the host
is switched to 'connecting' state due to its load regarding number of
running VMs and SPM status, in the case of soft-fencing flow, the host
is already in not-responding status, other host already took the SPM
role and all its running VMs set to 'unknown' status. So we should not
consider the host load at all and a fixed grace period (configurable 1
min) is enough to restart the vdsmd service on the host and get it up
and running.
Solution was tested with host as SPM with running VMs (some are HA),
with a non SPM host running VMs and with a regular host.
Results:
1. Both initial grace between connecting and non-responding and between
soft-fencing and hard-fencing are honored.
2. Code is more readable and straight foreword
Signed-off-by: Eli Mesika <emesika@redhat.com>
Bug-Url: https://bugzilla.redhat.com/2071468
emesika
requested review from
mwperina,
ahadas,
bennyz,
michalskrivanek,
oliel,
sgratch and
didib
as code owners
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 patch fixes network exception handling and fencing flow logic.
Problems in current code:
While we have to handle the network exception grace period when the host
is switched to 'connecting' state due to its load regarding number of
running VMs and SPM status, in the case of soft-fencing flow, the host
is already in not-responding status, other host already took the SPM
role and all its running VMs set to 'unknown' status. So we should not
consider the host load at all and a fixed grace period (configurable 1
min) is enough to restart the vdsmd service on the host and get it up
and running.
Solution was tested with host as SPM with running VMs (some are HA),
with a non SPM host running VMs and with a regular host.
Results:
Both initial grace between connecting and non-responding and between
soft-fencing and hard-fencing are honored.
Code is more readable and straight foreword
Signed-off-by: Eli Mesika emesika@redhat.com
Bug-Url: https://bugzilla.redhat.com/2071468