[ClusterLabs] Antw: Pacemaker ordering constraints and resource failures

[Ulrich Windl]

Hi!

I think your "problem" is that a master/slave resource is not two resources
with an oredering in between, but two resources that have special roles, and
there is an ordering regarding their roles.
So usually if you have one ms resource that one will try to become master (if
possible). the second one will become slave. If the master is stopped, the
slave will be promoted as slave.
I guess when following the logged actions it should become more clear.
I also think the dummy resource is not a typical candidate for an ms
resource.

Regards,
Ulrich
P.S. German Heat Wave: 26.5°C/80°F in the office already...

>>> "Devin A. Bougie" <devin.bougie at cornell.edu> schrieb am 06.08.2018 um
19:07 in
Nachricht <777B4583-8462-4BED-A3E7-9AF77C117B5F at cornell.edu>:
> What is the best way to make sure pacemaker doesn’t attempt to recover or 
> restart a resource if a resource it depends on is not started?
> 
> For example, we have two dummy resources that simply sleep - master_sleep 
> and slave_sleep.  We then have a non-symmetrical ordering constraint that 
> ensures master_sleep is started before slave_sleep:
>   start master_sleep then start slave_sleep (kind:Mandatory) 
> (non-symmetrical)
> 
> This works as expected when both resources are disabled.  If we enable 
> slave_sleep first, it won’t actually start until after master_sleep if 
> enabled and started.
> 
> However, if slave_sleep dies when master_sleep is disabled and stopped, 
> pacemaker recovers and restarts slave_sleep.  For example:
> - enable master_sleep, and wait for it to start
> - enable slave_sleep, and wait for it to start
> - disable master_sleep, and wait for it to stop
> - kill the slave_sleep process (or, “pcs resource debug-stop slave_sleep”)
> - pacemaker recovers and restarts slave_sleep, even though master_sleep is 
> disabled and stopped.
> 
> Is this the expected behavior, and is there any way to change it?  I’m happy

> to provide logs if that would help.
> 
> Many thanks,
> Devin