[ClusterLabs] multiple =?utf-8?Q?action=3D_?=lines sent to STDIN of fencing agents - why?

[Marek marx Grác]

Hi,


On 15 October 2015 at 16:45:58, Jan Pokorný (jpokorny at redhat.com) wrote:
> 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?

Fence agents do not use this mechanism for adding a values for attributes. So if multiple values of actions occur, it is done by user manually. By default, if action is not defined it is reboot (or off).

In case of pacemaker (pcmk_*_action), the action is added according to pcmk_*_action settings. 


> > 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.

	Info was added to the wiki page was added


> 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.

	Emit a message when such situation occurs is a bit tricky but doable. The problem is in fact that we use ‘default’ values for some attributes and later in program we can’t distinguish who entered the value. So in some cases, the warning will not be emit.

m,