[ClusterLabs] Antw: Re: Q: ordering for a monitoring op only?

2018-08-20 Thread Ulrich Windl
>>> Ken Gaillot schrieb am 20.08.2018 um 16:49 in Nachricht <1534776566.6465.5.ca...@redhat.com>: > On Mon, 2018‑08‑20 at 10:51 +0200, Ulrich Windl wrote: >> Hi! >> >> I wonder whether it's possible to run a monitoring op only if some >> specific resource is up. >> Background: We have some

[ClusterLabs] Antw: Re: Q: Stickyness across resource restarts

2018-08-20 Thread Ulrich Windl
>>> Ken Gaillot schrieb am 20.08.2018 um 17:11 in Nachricht <1534777874.6465.7.ca...@redhat.com>: > On Thu, 2018‑08‑16 at 12:50 +0200, Ulrich Windl wrote: >> Hi! >> >> I have a question, specifically whether this behavior changed not too >> long ago: >> AFAIR, stickyness only affected running

[ClusterLabs] Different Times in the Corosync Log?

2018-08-20 Thread Eric Robinson
The corosync log show different times for lrmd messages than for cib or crmd messages. Note the 4 hour difference. What? Aug 20 13:08:27 [107884] 001store01acib: info: cib_perform_op: +

Re: [ClusterLabs] Q: ordering for a monitoring op only?

2018-08-20 Thread Jan Pokorný
On 20/08/18 10:51 +0200, Ulrich Windl wrote: > I wonder whether it's possible to run a monitoring op only if some > specific resource is up. > Background: We have some resource that runs fine without NFS, but > the start, stop and monitor operations will just hang if NFS is > down. In effect the

Re: [ClusterLabs] Q: Stickyness across resource restarts

2018-08-20 Thread Ken Gaillot
On Thu, 2018-08-16 at 12:50 +0200, Ulrich Windl wrote: > Hi! > > I have a question, specifically whether this behavior changed not too > long ago: > AFAIR, stickyness only affected running resources, i.e. during > restart a new (=lightly loaded) node was selected for the resource. > However when

Re: [ClusterLabs] Q: ordering for a monitoring op only?

2018-08-20 Thread Ken Gaillot
On Mon, 2018-08-20 at 10:51 +0200, Ulrich Windl wrote: > Hi! > > I wonder whether it's possible to run a monitoring op only if some > specific resource is up. > Background: We have some resource that runs fine without NFS, but the > start, stop and monitor operations will just hang if NFS is

Re: [ClusterLabs] Q: Forcing a role change of master/slave resource

2018-08-20 Thread Ken Gaillot
On Mon, 2018-08-20 at 10:41 +0200, Ulrich Windl wrote: > Hi! > > Browsing the documentation, I'm still woindering whether this is > possible: > Make a master/slave resource change roles, i.e.: master becomes > slave, slave becomes master, preferrably without stopping the master. > The

Re: [ClusterLabs] Spurious node loss in corosync cluster

2018-08-20 Thread Ken Gaillot
On Sun, 2018-08-19 at 17:35 +0530, Prasad Nagaraj wrote: > Hi: > > One of these days, I saw a spurious node loss on my 3-node corosync > cluster with following logged in the corosync.log of one of the > nodes. > > Aug 18 12:40:25 corosync [pcmk  ] notice: pcmk_peer_update: > Transitional

Re: [ClusterLabs] Q: ordering for a monitoring op only?

2018-08-20 Thread Kristoffer Grönlund
On Mon, 2018-08-20 at 10:51 +0200, Ulrich Windl wrote: > Hi! > > I wonder whether it's possible to run a monitoring op only if some > specific resource is up. > Background: We have some resource that runs fine without NFS, but the > start, stop and monitor operations will just hang if NFS is

[ClusterLabs] Q: ordering for a monitoring op only?

2018-08-20 Thread Ulrich Windl
Hi! I wonder whether it's possible to run a monitoring op only if some specific resource is up. Background: We have some resource that runs fine without NFS, but the start, stop and monitor operations will just hang if NFS is down. In effect the monitor operation will time out, the cluster

[ClusterLabs] Q: Forcing a role change of master/slave resource

2018-08-20 Thread Ulrich Windl
Hi! Browsing the documentation, I'm still woindering whether this is possible: Make a master/slave resource change roles, i.e.: master becomes slave, slave becomes master, preferrably without stopping the master. The documentation for "crm_resource --ban --master ..." is somewhat vague: Will it