Hi, On 20-Nov-10, at 12:47 AM, Andrew Beekhof wrote:
> What do you think you gain by not increasing the timeout? > We don't sit around doing nothing if it completes in only a fraction > of the allocated time. > It's possible I should increase it. The problem is that I'm not aware of an upper bound on the time it takes an elastic IP on AWS to be reassigned from one node to another, so I wasn't really sure how to set the value. Mostly, though, I want to ensure that the IPs are always bound to some host (i.e. the IP resources should never be stopped or unmanaged, except for a lack of running nodes). Since I had to run the monitor check once every 60-90s anyway, I figured that would take care of any failed previous runs. > In any case, if you really want, check out the start-failure-is-fatal > option (man pengine). I couldn't track down this man page (it is apparently missing from the Debian packages). The guide "Pacemaker 1.0: Configuration Explained" says that "when set to false, the cluster will instead use the resource's failcount and value for resource-failure-stickiness". Am I correct in thinking that if this value is set to true and a resource fails to start, it is kicked into unmanaged mode? > Did you set cluster-recheck-interval appropriately? (man crmd) Nope -- that did it, thanks. Another question -- is it possible to define resources that do not have stop actions? On AWS, there is no need to explicitly stop an elastic IP before reassigning it to another node (the IP will be automatically released from a host before it is assigned to another). Doing so unnecessarily slows down the IP flip operation. I've played around a bit with making the stop action in the resource script be a no-op that always returns OCF_SUCCESS. This seems to work, but I can imagine that there will be situations where Pacemaker may get confused (a call to "monitor" will show a resource is still running, even though an immediately prior call to "stop" returned success). Thanks, Andrew _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
