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.19 #10059 +/- ##
=========================================
Coverage 15.16% 15.17%
- Complexity 11335 11340 +5
=========================================
Files 5412 5412
Lines 475042 475045 +3
Branches 57963 57964 +1
=========================================
+ Hits 72060 72080 +20
+ Misses 394924 394905 -19
- Partials 8058 8060 +2
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.
Resolve the issur : Should not shutting down a server which is already shut. Thanks for DaanHoogland which provide code.
|
|
@leo79901 , can you please share any test results or other experience with this? |
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?