Hi Lars,
Thank you for your reply!
Lars Marowsky-Bree wrote:
(snip)
There is one missing bit though; a node not doing kdump needs to be
STONITH'ed; so, failure of the kdump-stonith plugin should "escalate" to
the next plugin. I'm not sure the current STONITH subsystem can handle
this.
I think it is possible by making a plugin which has ability to spoil and
a kdump-check plugin group.
And by making kdump-check plugin return ERROR when it detects that
the target node is not dumping.
As far as I confirm, if the first plugin in a group is failed,
the second one is executed.
(If it is an unexpected behavior, please let me know the correct one.)
However, a timeout-problem comes here.
Under present STONITH, when a plugin takes long time,
parent-stonithd's timeout occurs,
and STONITH function starts again from the beginning
(from creating a graph).
This means that the behavior in the case of a plugin takes long time is
different from that in the case of it returns ERROR.
Second, I would like to hear your opinion about the following.
I think a timeout setting shuold be necessary for STONITH plugin.
(snip)
Yes, being able to somehow specify a per-plugin "fence" timeout would be
useful. The "start" and "stop" timeouts can be set, but not the actual
stonith ops ...
I think it would make sense if they could be specified as regular
operations in the CIB, and then would be passed to stonithd somewhow.
Now I'm pondering exactly on it.
It is easy way to add fixed attributes (like "fence-timeout")
to each plugin's instance_attributes, and get it's value from params in
stonith_rsc_t...
But maybe it is more proper way to add new op "fence" and add an element
(like "child_timeout" or "fence_timeout" or something)
to stonith_ops_t, I think...
In addition, maybe it is necessary to pass "fence_timeout"
to tengine too, not only to stonithd.
TE has its own timeout setting for STONITH, so
it is necessary to extend that depending on each plugin's
timeout setting, even if two or more plugins are set in a group.
Best Regards,
Satomi Taniguchi
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/