[ClusterLabs] fence agent configuration (was: fencing on iscsi device not working)

[Ken Gaillot]

On Thu, 2019-11-07 at 10:16 +0100, wferi at niif.hu wrote:
> Ken Gaillot <kgaillot at redhat.com> writes:
> 
> > I edited it so that the default and description are combined:
> > 
> > How to determine which machines are controlled by the device.
> > Allowed
> > values:
> > 
> > * +static-list:+ check the +pcmk_host_list+ or +pcmk_host_map+
> > attribute (this is the default if either one of those is set)
> > 
> > * +dynamic-list:+ query the device via the "list" command (this is
> > otherwise the default if the fence device supports the list action)
> > 
> > * +status:+ query the device via the "status" command (this is
> > otherwise the default if the fence device supports the status
> > action)
> > 
> > * +none:+ assume every device can fence every machine (this is
> > otherwise the default)
> 
> Before getting to typography: how can the status command help
> determining which machines are controlled by the device?

Status is not the same for fence agents as for resource agents. The
fence agents "monitor" action is what is used for recurring monitors.

For fence agents, "list" and "status" are two different common commands
for determining targets. "list" outputs a list of all possible targets.
"status" takes a node name and returns whether it is a possible target.
Fence agents are not required to support either one.

> Ignoring that, the explanation could be simplified by stating upfront
> that pcmk_host_check is ignored if pcmk_host_list or pcmk_host_map is
> set, and pcmk_host_list is ignored if pcmk_host_map is set (maybe
> start
> issuing a warning now and forbid these outright later).  Heck, if not
> for status, pcmk_host_check could be dropped altogether by doing:
> 
> 1. use pcmk_host_map if defined
> 2. use pcmk_host_list if defined
> 3. query the device if it supports the list command
> 4. assume that the device is universal

That's what the default is for, so most people can ignore it :)

The option allows for more complicated scenarios. For example a user
could force "none" even if the device supports list and/or status, in
case those are supported but unreliable or slow. Or a user could force
"status" but still supply pcmk_host_map to send the status command a
different name than the node name.

FYI, pcmk_host_map and pcmk_host_list can be used together. Anything in
pcmk_host_list but not pcmk_host_map will behave as if it were in
pcmk_host_map mapping to the same name. This could be convenient for
example if all the cluster nodes are fenced by their own name (and thus
can be put in pcmk_host_list), while some remote nodes must be fenced
under a different hostname (and thus must be pcmk_host_map).

> 
> It should also been clarified whether Pacemaker passes the port or
> the
> nodename attribute to the fence agent in the above cases.
> https://github.com/ClusterLabs/fence-agents/blob/master/doc/FenceAgentAPI.md
-- 
Ken Gaillot <kgaillot at redhat.com>