Hi,
On 26-Nov-10, at 1:41 AM, Andrew Beekhof wrote:
>> The problem here is that these spurious node failures cause Pacemaker
>> to initiate unnecessary resource migrations. Is it normal for the
>> cluster to become confused for a while when the network connection to
>> a node is suddenly restore
Hi,
I'm curious how the "on-fail" attribute of a recurring monitor
operation works. From my testing, it seems that a recurring monitor
is considered to have failed any time its return doesn't match what
the cluster believes it should be. That is, if the resource is
supposed to be running
Hi,
On 25-Nov-10, at 11:37 AM, Andrew Beekhof wrote:
> Given what you've described, you could probably remove the while loop
> during stop.
> It should be safe because Amazon is ensuring that it will only "run"
> in exactly one location.
I'll give that a try -- thanks.
I noticed something else
Hi,
On 23-Nov-10, at 3:52 AM, Andrew Beekhof wrote:
>> 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
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
Hi all,
I'm trying to use Pacemaker on a Amazon Web Services' EC2 to
automatically reassign elastic IPs (Amazon's equivalent to floating or
virtual IPs) in the event of a node failure. The setup I'm testing
with is two elastic IPs which will be assigned to any pair of hosts in
a three nod
