Hi sbd - developers & users! Thanks to everybody for contributing to tests and further development.
Improvements in build/CI-friendlyness and added robustness against misconfiguration justify labeling the repo v1.4.2. I tried to quickly summarize the changes in the repo since it was labeled v1.4.1: - improve build/CI-friendlyness * travis: switch to F32 as build-host switch to F32 & leap-15.2 changes for mock-2.0 turn off loop-devices & device-mapper on x86_64 targets because of changes in GCE * regressions.sh: get timeouts from disk-header to go with proper defaults for architecture * use configure for watchdog-default-timeout & others * ship sbd.pc with basic sbd build information for downstream packages to use * add number of commits since version-tag to build-counter - add robustness against misconfiguration / improve documentation * add environment section to man-page previously just available in template-config * inform the user to restart the sbd service after disk-initialization * refuse to start if any of the configured device names is invalid * add handshake to sync startup/shutdown with pacemakerd Previously sbd just waited for the cib-connnection to show up/go away which isn't robust at all. The new feature needs new pacemakerd-api as counterpart. Thus build checks for presence of pacemakerd-api. To simplify downstream adoption behavior is configurable at runtime via configure-file with a build-time-configurable default. * refuse to start if qdevice-sync_timeout doesn't match watchdog-timeout Needed in particular as qdevice-sync_timeout delays quorum-state-update and has a default of 30s that doesn't match the 5s watchdog-timeout default. - Fix: sbd-pacemaker: handle new no_quorum_demote + robustness against new policies added - Fix: agent: correctly compare string values when calculating timeout - Fix: scheduling: overhaul the whole thing * prevent possible lockup when format in proc changes * properly get and handle scheduler policy & prio * on SCHED_RR failing push to the max with SCHED_OTHER Regards, Klaus _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/developers ClusterLabs home: https://www.clusterlabs.org/