add check before fencing #10059
add check before fencing #10059
Conversation
DaanHoogland
force-pushed
the
fenchCheck
branch
from
73ad3c7 to
7bb7d3f
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## 4.20 #10059 +/- ##
============================================
- Coverage 16.18% 16.18% -0.01%
- Complexity 13300 13301 +1
============================================
Files 5657 5657
Lines 498478 498481 +3
Branches 60501 60502 +1
============================================
- Hits 80668 80662 -6
- Misses 408827 408836 +9
Partials 8983 8983
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 11748 |
|
| // host exists and is managed OOB | ||
| if (r != null && outOfBandManagementService.isOutOfBandManagementEnabled(r)) { | ||
| // check host status | ||
| if (Status.Down.equals(r.getStatus())) { |
There was a problem hiding this comment.
@DaanHoogland, my concern here is that host's status could be Down but in reality to be still running. With this there is an option the virtual machines started to a neighbor host to be left running on the previous one.
Maybe it is better to check the OOBM status rather the host's.
Unfortunately now I don't have environment with IPMI setup and cannot test this change.
Probably here and @rp- could give some advice.
There was a problem hiding this comment.
True what @slavkap said, and now I'm a bit confused what actual the original issue was?
Wouldn't it be not just a noop if the host is already down and fence it again?
There was a problem hiding this comment.
Do you mean to change this condition to something else , @slavkap ?
If it is !Down a power operation will be performed. should it happen here as well?
I am not sure if we have a OOB status retrieval possibility.
There was a problem hiding this comment.
@rp-, there was a discussion about an issue with the fencing that the Host is Powered off and CS tries to shut it down again. But I've seen cases where the host could be in the down state before the IPMI tries to power it off.
@DaanHoogland, yes, I think there is an option to check the OOBM status and the condition should be changed with the result of it
There was a problem hiding this comment.
ok, it is not part of outOfBandManagementService.
|
|
@leo79901 , can you please share any test results or other experience with this? |
Resolve the issur : Should not shutting down a server which is already shut. Thanks for DaanHoogland which provide code.
DaanHoogland
force-pushed
the
fenchCheck
branch
from
f5dee3b to
50d4cf9
Compare
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
|
|
stale fix, will reopen when becomes active again |
7 participants
Resolve the issue : Should not shutting down a server which is already shut.
Description
This PR replaces #10055 on request of user.
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
How did you try to break this feature and the system with this change?