Hi, On Wed, Sep 24, 2008 at 05:30:35PM +0900, Satomi TANIGUCHI wrote: > Hi, > > Thank you very very much for your quick action, Dejan!! > > Dejan Muhamedagic wrote: >> 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". > OK, I see.
Actually, the order (in case there's no priority set) depends on when resources started. So, it's most probably true that they would be tried in order as in a group. Still, I think that specifying a priority is a more natural way since the stonith resource order should not actually have anything to do with the fencing operations. >>>>>> 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. > It worked pretty well with my quick check. Great. >>>> - 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? > Maybe, users are at a loss what to do when they want to set fence op's > timeout, I think. > Adding "stonith-timeout" in <instance_attributes> seems to be a better way... It would be very easy to implement that. But I'm still not sure if that's really a better way. Currently, the timeout is picked from the start operation and, if that's not set, from the fencing request which comes either from the crmd or stonithd itself. Well, if you insist, we could have the instance attribute override all other timeouts. > (adding "stonith" or "fence" operation in <operations> is an exaggerated way?) Yes, I think so. All operations refer to resources. Fencing is different. >> Satomi-san: It would be great if you can test these changes with >> your setup. > Certainly, with pleasure! > I'm doing now. > >> >>>> - 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? > All right. Andrew set this one straight. The cluster_delay shouldn't influence the fencing operations. >> BTW, it would probably be a good idea to have a stonith specific >> property. cluster_delay is namewise (and descriptionwise) a bit >> far fetched. > I agree. > But if it is possible, the value for this should be calculated automatically > based on each stonith plugin, I think. > Because an user does make a mistake. This is not needed. crmd should wait until stonithd reports back the result. Thanks, Dejan >>>> 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 again! > >> >> Thanks, >> >> Dejan >> _______________________________________________________ >> Linux-HA-Dev: [email protected] >> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev >> Home Page: http://linux-ha.org/ > > 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/ _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
