{{ ansible_managed | comment }}
{{ "system_role:ha_cluster" | comment(prefix="", postfix="") }}

{% macro option(ansible_name, default_value) -%}
  {%- for option in options if option.name == ansible_name -%}
    {{ option.value | string }}
  {%- else -%}
    {{ default_value }}
  {%- endfor -%}
{%- endmacro %}

## Type: string
## Default: ""
#
# SBD_DEVICE specifies the devices to use for exchanging sbd messages
# and to monitor. If specifying more than one path, use ";" as
# separator.
#
{% if node_devices | d([]) %}
SBD_DEVICE="{{ node_devices | join(';') }}"
{% else %}
SBD_DEVICE=""
{% endif %}

## Type: yesno
## Default: yes
#
# Whether to enable the pacemaker integration.
#
SBD_PACEMAKER=yes

## Type: always / clean
## Default: always
#
# Specify the start mode for sbd. Setting this to "clean" will only
# allow sbd to start if it was not previously fenced. See the -S option
# in the man page.
#
SBD_STARTMODE="{{ option('startmode', 'always') }}"

## Type: yesno / integer
## Default: no
#
# Whether to delay after starting sbd on boot for "msgwait" seconds.
# This may be necessary if your cluster nodes reboot so fast that the
# other nodes are still waiting in the fence acknowledgement phase.
# This is an occasional issue with virtual machines.
#
# This can also be enabled by being set to a specific delay value, in
# seconds. Sometimes a longer delay than the default, "msgwait", is
# needed, for example in the cases where it's considered to be safer to
# wait longer than:
# corosync token timeout + consensus timeout + pcmk_delay_max + msgwait
#
# Be aware that the special value "1" means "yes" rather than "1s".
#
# Consider that you might have to adapt the startup-timeout accordingly
# if the default isn't sufficient. (TimeoutStartSec for systemd)
#
# This option may be ignored at a later point, once pacemaker handles
# this case better.
#
SBD_DELAY_START="{{ option('delay-start', 'no') }}"

## Type: string
## Default: /dev/watchdog
#
# Watchdog device to use. If set to /dev/null, no watchdog device will
# be used.
#
SBD_WATCHDOG_DEV="{{ node_watchdog | d('/dev/watchdog') }}"

## Type: integer
## Default: 5
#
# How long, in seconds, the watchdog will wait before panicking the
# node if no-one tickles it.
#
# This depends mostly on your storage latency; the majority of devices
# must be successfully read within this time, or else the node will
# self-fence.
#
# If your sbd device(s) reside on a multipath setup or iSCSI, this
# should be the time required to detect a path failure.
#
# Be aware that watchdog timeout set in the on-disk metadata takes
# precedence.
#
SBD_WATCHDOG_TIMEOUT="{{ option('watchdog-timeout', '5') }}"

## Type: string
## Default: "flush,reboot"
#
# Actions to be executed when the watchers don't timely report to the sbd
# main process or one of the watchers detects that the main process has
# died.
#
# Set timeout-action to comma-separated combination of
# noflush|flush plus reboot|crashdump|off.
# If just one of both is given the other stays at the default.
#
# This doesn't affect actions like off, crashdump, reboot explicitly
# triggered via message slots.
# And it does as well not configure the action a watchdog would
# trigger should it run off (there is no generic interface).
#
SBD_TIMEOUT_ACTION="{{ option('timeout-action', 'flush,reboot') }}"

## Type: yesno / auto
## Default: auto
#
# If CPUAccounting is enabled default is not to assign any RT-budget
# to the system.slice which prevents sbd from running RR-scheduled.
#
# One way to escape that issue is to move sbd-processes from the
# slice they were originally started to root-slice.
# Of course starting sbd in a certain slice might be intentional.
# Thus in auto-mode sbd will check if the slice has RT-budget assigned.
# If that is the case sbd will stay in that slice while it will
# be moved to root-slice otherwise.
#
SBD_MOVE_TO_ROOT_CGROUP=auto

## Type: yesno
## Default: yes
#
# If resource startup syncing is enabled then pacemakerd is
# gonna wait to be pinged via IPC before it starts resources.
# On shutdown pacemakerd is going to wait in a state where it
# has cleanly shutdown resources till sbd fetches that state.
#
# The default is set when building SBD and Pacemaker from source.
# Going for 'no' is safer if it can't be assured that SBD and
# Pacemaker installed do both support the synchronization feature.
# When going with 'yes' - also using package dependencies to
# assure SBD & Pacemaker both support the synchronization
# feature and are assuming the same default - an SBD configuration
# inherited via an upgrade doesn't have to be altered to still
# benefit from the new feature.
#
SBD_SYNC_RESOURCE_STARTUP=yes

## Type: string
## Default: ""
#
# Additional options for starting sbd
#
SBD_OPTS="-n {{ node_name }}"
