[ClusterLabs] Clearing failed actions

Hi, I found a web page which suggested to clear the Failed Actions, to use `crm_resource -P`. Although this appears to work, it's not documented on the man page at all. Is this deprecated and is there a more correct way to be doing this? Also, is there a way to clear one specific item from

[ClusterLabs] Clearing "Failed Actions"

I found a random web page which suggested to clear the Failed Actions, to use `crm_resource -P`. Although this appears to work, it's not documented on the man page at all. Is this deprecated and is there a more correct way to be doing this? Cheers, -- Casey

[ClusterLabs] Pacemaker 2.0.0 has been released

I am very happy to announce that source code for the final release of Pacemaker version 2.0.0 is now available at: https://github.com/ClusterLabs/pacemaker/releases/tag/Pacemaker-2.0.0 The main goal of the change from Pacemaker 1 to 2 is to drop support for deprecated legacy usage, in order to

Re: [ClusterLabs] Pacemaker alert framework

On Fri, 2018-07-06 at 15:58 +0200, Klaus Wenninger wrote: > On 07/06/2018 03:41 PM, Ian Underhill wrote: > > requirement: > > when a resource fails perform an actionm, run a script on all nodes > > within the cluster, before the resource is relocated. i.e. > > information gathering why the

Re: [ClusterLabs] Pacemaker alert framework

On 07/06/2018 03:41 PM, Ian Underhill wrote: > requirement: > when a resource fails perform an actionm, run a script on all nodes > within the cluster, before the resource is relocated. i.e. information > gathering why the resource failed. Have in mind that trying to run a script on all nodes in

[ClusterLabs] Pacemaker alert framework

requirement: when a resource fails perform an actionm, run a script on all nodes within the cluster, before the resource is relocated. i.e. information gathering why the resource failed. what I have looked into: 1) Use the monitor call within the resource to SSH to all nodes, again SSH config

Re: [ClusterLabs] Upgrade corosync problem

Hi, Thanks to reply. The problem is opposite to what you are saying. When I build corosync with old libqb and I verified the new updated node worked properly I updated with new libqb hand-compiled and it works fine. But in a normale upgrade procedure I first build libqb (removing first the old

Re: [ClusterLabs] Upgrade corosync problem

On 06/07/18 13:24, Salvatore D'angelo wrote: > Hi All, > > The option --ulimit memlock=536870912 worked fine. > > I have now another strange issue. The upgrade without updating libqb > (leaving the 0.16.0) worked fine. > If after the upgrade I stop pacemaker and corosync, I download the > latest

Re: [ClusterLabs] Upgrade corosync problem

Here some strike of corosync: execve("/usr/sbin/corosync", ["corosync"], [/* 21 vars */]) = 0 brk(0) = 0x563b1f774000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file

Re: [ClusterLabs] Upgrade corosync problem

Hi All, The option --ulimit memlock=536870912 worked fine. I have now another strange issue. The upgrade without updating libqb (leaving the 0.16.0) worked fine. If after the upgrade I stop pacemaker and corosync, I download the latest libqb version:

Re: [ClusterLabs] Found libqb issue that affects pacemaker 1.1.18

On 06/07/18 10:09, Salvatore D'angelo wrote: > I closed the issue. > Libqb uses tagging and people should not download the Source code (zip) >  or Source > code (tar.gz) . > The