[ClusterLabs] Trying to Understanding crm-fence-peer.sh

[Bryan K. Walton]

On Wed, Jan 16, 2019 at 04:53:32PM +0100, Lars Ellenberg wrote:
> 
> To clarify: crm-fence-peer.sh is an *example implementation*
> (even though an elaborate one) of a DRBD fencing policy handler,
> which uses pacemaker location constraints on the Master role
> if DRBD is not sure about the up-to-date-ness of that instance,
> to ban nodes from taking over the Master role.
> 
> It does NOT trigger node level fencing.
> But it has to wait for, and rely on, pacemaker node level fencing.

Thanks Lars.  Between these comments, and the man page for drbd.conf, I
think I understand what is going on here.  Is it correct to say, that in
the case I provided, that DRBD successfully issued a "drbdadm outdate
res" on the other node, and therefore it didn't need to STONITH the
peer?  (Looking at the crm-fence-peer code, I see that exit code 4 is
node fenced, but there is an exit code 7 which means STONITHED.  In my
case, I got an exit code 4, and not a 7.)

Also you mentioned that "Other implementations of drbd fencing policy
handlers may directly escalate to node level fencing."

Are these "other implementations" third-party handlers?  Or are they
available from within the DRBD software? Can you point to any of these?

Thanks!
Bryan