[ClusterLabs] multiple action= lines sent to STDIN of fencing agents - why?

Jan Pokorný jpokorny at redhat.com
Thu Oct 15 10:45:16 EDT 2015


On 15/10/15 12:25 +0100, Adam Spiers wrote:
> I inserted some debugging into fencing.py and found that stonithd
> sends stuff like this to STDIN of the fencing agents it forks:
> 
>     action=list
>     param1=value1
>     param2=value2
>     param3=value3
>     action=list
> 
> where paramX and valueX come from the configuration of the primitive
> for the fencing agent.
> 
> As a corollary, if the primitive for the fencing agent has 'action'
> defined as one of its parameters, this means that there will be three
> 'action=' lines, and the middle one could have a different value to
> the two sandwiching it.
> 
> When I first saw this, I had an extended #wtf moment and thought it
> was a bug.  But on closer inspection, it seems very deliberate, e.g.
> 
>   https://github.com/ClusterLabs/pacemaker/commit/bfd620645f151b71fafafa279969e9d8bd0fd74f
> 
> The "regardless of what the admin configured" comment suggests to me
> that there is an underlying assumption that any fencing agent will
> ensure that if the same parameter is duplicated on STDIN, the final
> value will override any previous ones.  And indeed fencing.py ensures
> this, but presumably it is possible to write agents which don't use
> fencing.py.
> 
> Is my understanding correct?  If so:
> 
> 1) Is the first 'action=' line intended in order to set some kind of
>    default action, in the case that the admin didn't configure the
>    primitive with an 'action=' parameter *and* _action wasn't one of
>    list/status/monitor/metadata?  In what circumstances would this
>    happen?
> 
> 2) Is this assumption of the agents always being order-sensitive
>    (i.e. last value always wins) documented anywhere?  The best
>    documentation on the API I could find was here:
> 
>       https://fedorahosted.org/cluster/wiki/FenceAgentAPI
> 
>    but it doesn't mention this.

Agreed that this implicit and undocumented arrangement smells fishy.

In fact I raised this point within RH team 3 month back but there
wasn't any feedback at that time.  Haven't filed a bug because it's
unclear to me what's intentional and what's not between the two
interacting sides.  Back then, I was proposing that fencing.py should,
at least, emit a message about subsequent parameter overrides.

Note that "port" parameter (or whatever is the correct way to specify
a victim in the particular case) is affected as well.

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20151015/f5911ca2/attachment-0003.sig>


More information about the Users mailing list