On Fri, Sep 19, 2008 at 09:00, Satomi TANIGUCHI <[EMAIL PROTECTED]> wrote:
[snip] >>> I implemented a prototype, and it seems to work well. >>> I would like to hear your opinions. >> >> Personally I think this is unnecessarily complicated. >> >> I'm sure what you have works well, but would favor a single >> stonith-timeout configuration option which it is up to the admin to >> set appropriately (passed to the TE in the same way as cluster-delay). > > Is "stonith-timeout" a configuration option per cluster? > (In other words, is it written in <cluster_property_set>?) Not yet, because it doesn't exist. But yes, that is the intention. > > I consider it is better to be able to set timeout value for each STONITH > plugin > as if we can set the value for each resource. > Because each STONITH device has its own characteristic. Right, but by far the most common scenario is to only have one type of plugin. > >> >> In my opinion, this would be sufficient for most scenarios^ and the >> chance of it being configured correctly is much higher. >> It also requires a whole lot less CPU to figure out what value to use ;-) > > Yes. > less CPU is one of the most important matters for customers! Well you can't have both :) > >> >> >> ^ Clusters with multiple types of devices can simply pick the highest >> timeout and clusters with cascaded stonith setups (is that even >> possible at the moment?) just add all the timeouts all together. > > I'm confused. > With this sentence, it seems that "stonith-timeout" is an option per > plugin... No. What I meant was that the admin should determine what timeout all the plugins need and use those values to set the global stonith-timeout appropriately. I've amended my reply below: >> ^ [For] Clusters with multiple types of devices [, admins] can simply pick >> the highest >> timeout and [for] clusters with cascaded stonith setups (is that even >> possible at the moment?) [admins should] just add all the timeouts all >> together. Actually, looking again at your proposal, you have the core of an acceptable idea but its the implementation I really dislike. If the admin is configuring timeouts, then there is really no need to get the CRM involved at all (step 3). And combining everything into a single CRM_meta_stonith_plugin_dataset field is unnecessary and ugly. 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? Btw. if NTT wants this in for 1.0, then you guys need to be _very_ quick writing the patch. > > Cascaded stonith setup can be realized by setting two or more plugins in a > group > at the moment. > 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. > 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 :-) _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
