On Fri, Sep 19, 2008 at 05:28:42PM +0200, Andrew Beekhof wrote: > On Fri, Sep 19, 2008 at 16:44, Dejan Muhamedagic <[EMAIL PROTECTED]> wrote: > > 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) > > ack
This is implemented in the development branch: http://hg.clusterlabs.org/pacemaker/dev/rev/a3a62aa43d64 The priorities are set with the "priority" instance attribute. The lower the number, the higher the priority. > > - fencing operation timeouts per stonith resource (stonithd) > > ack http://hg.clusterlabs.org/pacemaker/dev/rev/0f17d8472570 http://hg.clusterlabs.org/pacemaker/dev/rev/785fb0d9d821 The timeouts are taken from the "start" operation. Even though it may not be obvious that this timeout is used for the fencing operations as well, I think that it still makes more sense than making an extra instance attribute. Any objections? Satomi-san: It would be great if you can test these changes with your setup. > > - global fencing timeout (crm cluster property) > > Or, we totally ignore this and rely solely on the per-resource value above. > I'd vote for that for the sake of consistency (otherwise its > non-obvious which value takes precedence) That's how it works right now. The users should take care of setting the cluster_delay properly, i.e. to the maximum possible stonith timeout and then double that. Right? BTW, it would probably be a good idea to have a stonith specific property. cluster_delay is namewise (and descriptionwise) a bit far fetched. > > 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? > > The timing... if people want this for 1.0, then someone needs to get a > patch to me by the 24th (Wednesday) at the latest. > There'll be no more features after then (bugfixes are of course ok, > just no new features). On time. Thanks, Dejan _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
