On Wed, Sep 24, 2008 at 16:17, Dejan Muhamedagic <[EMAIL PROTECTED]> wrote: >>> 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.
Can we please pick one way and go with that? (I don't much care which). There is such a thing (as exemplified by the 0.6 configuration) as _too_ much choice. >>> 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. Correct. Now that stonith operations have their own timeouts, the cluster should simply wait forever for it to return (except of course if stonithd dies :-) So if you find cluster_delay is being used, its a bug. _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
