Dev: ui_sbd: Check sbd health before running 'crm sbd' subcommands

[liangxin1300]

Call SBD.check_sbd_health() before running:

• crm sbd configure
• crm sbd device
• crm sbd purge

Return False if SBD health check fails

[codecov]

Codecov Report

❌ Patch coverage is 22.22222% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 70.41%. Comparing base (8409ea5) to head (5141b70).
⚠️ Report is 2 commits behind head on master.

Files with missing lines	Patch %	Lines
crmsh/ui_sbd.py	22.22%	7 Missing ⚠️

Additional details and impacted files

Flag	Coverage Δ
integration	55.32% <0.00%> (-0.02%)	⬇️
unit	52.39% <22.22%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
crmsh/ui_sbd.py	82.84% <22.22%> (-1.10%)	⬇️

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[nicholasyang2022]

IMO users should be able to change config or purge the SBD when it is unhealthy.

[liangxin1300]

IMO users should be able to change config or purge the SBD when it is unhealthy.

They can use crm cluster health sbd --fix to fix at first
@zzhou1 What do you think?

[nicholasyang2022]

IMO users should be able to change config or purge the SBD when it is unhealthy.

They can use crm cluster health sbd --fix to fix at first

After considering the scenarios carefully, I still have strong concerns about blocking these subcommands, because it would block administrators from disaster recovery. In case of hardware(disk/network) failure, crm cluster health sbd --fix will not help, and blocking the subcommands make it impossible to move to another disk.

And it is also counter-productive when users' goal is to purge SBD. When they just want to get rid of SBD, they should not be force to troubleshoot first.