Hi, On Fri, Sep 19, 2008 at 11:17:34AM +0200, Andrew Beekhof wrote: > On Fri, Sep 19, 2008 at 09:00, Satomi TANIGUCHI > <[EMAIL PROTECTED]> wrote: > > [snip] > > If you _really_ want to have a per-plugin value, I suggest making it > an extra resource parameter (ie. like hostlist) and teach stonithd to > look for and use it _instead_of_ the CRM-supplied value. > > Dejan: Any objections to something like this?
No. > > Cascaded stonith setup can be realized by setting two or more plugins in a > > group > > at the moment. I don't think so. Currently, all stonith plugins (coming from various stonith resources) are tried in turn until one succeeds, but there is no ordering. The information about them being grouped is lost, i.e. stonithd has no idea which stonith plugin should be invoked first. Another option (attribute) would have to be implemented, something like "priority". > > As far as I confirm, if the first plugin in a group is failed, > > the second one is executed. > > And if the first one succeeds, the second one is _not_ executed. Right. > > If it is an unexpected behavior, please let me know the correct one. > > Cool. I had no idea. I, like the CRM, am blissfully ignorant of how > STONITHd works :-) Good for you :) To summarize, we'd need the following new features: - stonith plugin priority (ordering of stonith resources) (stonithd) - fencing operation timeouts per stonith resource (stonithd) - global fencing timeout (crm cluster property) The global fencing timeout would have to be set either to the total of single timeouts or maximum timeout depending on the nature of devices. Any objections or pitfalls? Thanks, Dejan _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
