Hi,
2010/10/25 Andrew Beekhof :
> On Mon, Oct 25, 2010 at 7:49 AM, Junko IKEDA wrote:
>> or would it better not to increment the failcount?
>> in unpack_rsc_op(), demote operation is checked not to go into loop,
>> but promote is not.
>> see attached.
>
> the role remains correct though, and the
On Mon, Oct 25, 2010 at 7:49 AM, Junko IKEDA wrote:
> or would it better not to increment the failcount?
> in unpack_rsc_op(), demote operation is checked not to go into loop,
> but promote is not.
> see attached.
the role remains correct though, and the location constraint causes
the resource to
On Thu, Oct 21, 2010 at 11:10 AM, Junko IKEDA wrote:
> Hi,
>
> When the promote/demote action returns error code,
> it seems that failcount isn't incremented,
> so promote/demote action would go into a loop in some cases.
> Default settings for promote/demote are implicitly-defined
> (on_fail="res
or would it better not to increment the failcount?
in unpack_rsc_op(), demote operation is checked not to go into loop,
but promote is not.
see attached.
Thanks,
Junko
2010/10/21 Junko IKEDA :
> Hi,
>
> When the promote/demote action returns error code,
> it seems that failcount isn't incremented
Hi,
When the promote/demote action returns error code,
it seems that failcount isn't incremented,
so promote/demote action would go into a loop in some cases.
Default settings for promote/demote are implicitly-defined
(on_fail="restart" and interval=0).
Is it possible to handle them as in the case
