[ClusterLabs] Antw: [EXT] Re: Q: rulke-based operation pause/freeze?

[Ken Gaillot]

On Fri, 2020-03-06 at 08:19 +0100, Ulrich Windl wrote:
> > > > Ondrej <ondrej-clusterlabs at famera.cz> schrieb am 06.03.2020 um
> > > > 01:45 in
> 
> Nachricht
> <
> 7499_1583455563_5E619D4B_7499_1105_1_2a18c389-059e-cf6f-a840-dec26437fdd1 at famer
> .cz>:
> > On 3/5/20 9:24 PM, Ulrich Windl wrote:
> > > Hi!
> > > 
> > > I'm wondering whether it's possible to pause/freeze specific
> > > resource 
> > 
> > operations through rules.
> > > The idea is something like this: If your monitor operation needes
> > > (e.g.) 
> > 
> > some external NFS server, and thst NFS server is known to be down,
> > it seems
> > better to delay the monitor operation until NFS is up again, rather
> > than 
> > forcing a monitor timeout that will most likely be followed by a
> > stop 
> > operation that will also time out, eventually killing the node
> > (which has no
> > problem itself).
> > > 
> > > As I guess it's not possible right now, what would be needed to
> > > make this 
> > 
> > work?
> > > In case it's possible, how would an example scenario look like?
> > > 
> > > Regards,
> > > Ulrich
> > > 
> > 
> > Hi Ulrich,
> > 
> > To determine _when_ this state should be enabled and disabled would
> > be a 
> > different story.
> 
> For the moment let's assume I know it ;-) ping-node, maybe.

I believe that limited scenario is possible, but imperfectly.

You could configure an ocf:pacemaker:ping resource to ping the NFS
server IP. Then in the dependent resource, configure the recurring
monitor logically like this:

  monitor interval=N
     meta attributes
        rule when ping attribute lt 1 or not defined
        enabled=false

The node attribute will be changed only once the ping resource monitor
detects the IP gone, so there will be a window between when the IP
actually disappears and the node attribute is changed where the problem
could still occur. Also, the NFS server could have problems that do not
make the IP unpingable, and those situations would still have the
issue.
-- 
Ken Gaillot <kgaillot at redhat.com>