Actually I found some more details:
there are two resources: A and B
resource B depends on resource A (when the RA monitors B, if will fail if A is
not running properly)
If I stop resource A, the next monitor operation of "B" will fail.
Interestingly, this check happens immediately after A is
On 04/13/2017 08:49 AM, Radoslaw Garbacz wrote:
> Thank you, however in my case this parameter does not change the
> described behavior.
>
> I have a more detail example:
> order: res_A-clone -> res_B-clone -> res_C
> when "res_C" is not on the node, which had "res_A" instance failed, it
> will
- On May 8, 2017, at 9:20 PM, Bernd Lentes
bernd.len...@helmholtz-muenchen.de wrote:
> Hi,
>
> i remember that digimer often campaigns for a fence delay in a 2-node
> cluster.
> E.g. here:
> http://oss.clusterlabs.org/pipermail/pacemaker/2013-July/019228.html
> In my eyes it makes
On 09/05/17 09:51 -0500, Ken Gaillot wrote:
> On 05/09/2017 02:44 AM, Handra Cs wrote:
>> I am currently trying to configure Pacemaker/Corosync. I managed to
>> install the required packages for the cluster configuration, however I
>> could not start the cluster service. Based on the log file,
On 05/09/2017 03:51 AM, Lars Ellenberg wrote:
> Yay!
>
> On Mon, May 08, 2017 at 07:50:49PM -0500, Ken Gaillot wrote:
>> "crm_attribute --pattern" to update or delete all node
>> attributes matching a regular expression
>
> Just a nit, but "pattern" usually is associated with "glob pattern".
>
09.05.2017 00:56, Ken Gaillot wrote:
[...]
Those messages indicate there is a real issue with the CPU load. When
the cluster notices high load, it reduces the number of actions it will
execute at the same time. This is generally a good idea, to avoid making
the load worse.
[...]
message,
Yay!
On Mon, May 08, 2017 at 07:50:49PM -0500, Ken Gaillot wrote:
> "crm_attribute --pattern" to update or delete all node
> attributes matching a regular expression
Just a nit, but "pattern" usually is associated with "glob pattern".
If it's not a "pattern" but a "regex",
"--regex" would be
