[ClusterLabs] Pacemaker ordering constraints and resource failures

[Devin A. Bougie]

Many thanks for all of the replies.  Perhaps my choice of dummy resource names was misleading, as our production resources aren’t really in a master / slave relationship.  Just incase it helps, here is what we want to achieve.

- only start resource B if resource A is already running.
- if both resources are running and resource A stops, continue running resource B (hence the non-symmetrical ordering constraint)
- if resource B fails and resource A is disabled, resource B should not restart until resource A is started

It sounds like that should be doable with our existing constraints, so I’ll go ahead and open a bug at bugs.clusterlabs.org.

Thanks again!
Devin


> On Aug 6, 2018, at 1:07 PM, Devin A. Bougie <devin.bougie at cornell.edu> wrote:
> 
> 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