[ClusterLabs] Antw: Re: big trouble with a DRBD resource

[Ken Gaillot]

On Tue, 2017-08-08 at 10:18 +0200, Ulrich Windl wrote:
> >>> Ken Gaillot <kgaillot at redhat.com> schrieb am 07.08.2017 um 22:26 in Nachricht
> <1502137587.5788.83.camel at redhat.com>:
> 
> [...]
> > Unmanaging doesn't stop monitoring a resource, it only prevents starting
> > and stopping of the resource. That lets you see the current status, even
> > if you're in the middle of maintenance or what not. You can disable
> 
> This feature is discussable IMHO: If you plan to update the RAs, it seems a bad idea to run the monitor (that is part of the RA). Especially if a monitor detects a problem while in maintenance (e.g. the updated RA needs a new or changed parameter), it will cause actions once you stop maintenance mode, right?

Generally, it won't cause any actions if the resource is back in a good
state when you leave maintenance mode. I'm not sure whether failures
during maintenance mode count toward the migration fail count -- I'm
guessing they do but shouldn't. If so, it would be possible that the
cluster decides to move it even if it's in a good state, due to the
migration threshold. I'll make a note to look into that.

Unmanaging a resource (or going into maintenance mode) doesn't
necessarily mean that the user expects that resource to stop working. It
can be a precaution while doing other work on that node, in which case
they may very well want to know if it starts having problems.
 
You can already disable the monitors if you want, so I don't think it
needs to be changed in pacemaker. My general outlook is that pacemaker
should be as conservative as possible (in this case, letting the user
know when there's an error), but higher-level tools can make different
assumptions if they feel their users would prefer it. So, pcs and crm
are free to disable monitors by default when unmanaging a resource, if
they think that's better.

> My preference would be to leave the RAs completely alone while in maintenance mode. Leaving maintenance mode could trigger a re-probe to make sure the cluster is happy with the current state.
> 
> > monitoring separately by setting the enabled="false" meta-attribute on
> > the monitor operation.
> > 
> > Standby would normally stop all resources from running on a node (and
> > thus all monitors as well), but if a resource is unmanaged, standby
> > won't override that -- it'll prevent the cluster from starting any new
> > resources on the node, but it won't stop the unmanaged resource (or any
> > of its monitors).
> [...]
> 
> Regards,
> Ulrich
> 
> 
> 

-- 
Ken Gaillot <kgaillot at redhat.com>