Andrew Beekhof wrote:
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.
I agree.
I want to avoid complexity, too.
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.
Great.
Thanks a lot!
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/
