[ClusterLabs] multiple action= lines sent to STDIN of fencing agents - why?
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:
> 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.
> 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
> 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
> 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:
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Users