[ClusterLabs] Pacemaker ordering constraints and resource failures

[Ken Gaillot]

On Wed, 2018-08-08 at 20:55 +0300, Andrei Borzenkov wrote:
> 08.08.2018 16:59, Ken Gaillot пишет:
> > On Wed, 2018-08-08 at 07:36 +0300, Andrei Borzenkov wrote:
> > > 06.08.2018 20:07, Devin A. Bougie пишет:
> > > > 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 constraint tells the cluster to behave in the way you
> > described.
> > The "non-symmetrical" parts means that *only* starts are ordered:
> > slave_sleep cannot start until master_sleep has been started, but
> > it
> > can then run independently, regardless of whether master_sleep
> > stops or
> >  fails.
> > 
> 
> This does not actually answer the question. The question was not why
> slave_sleep remained started when master_sleep was stopped, but how
> could slave_sleep be (re-)started when master_sleep remained stopped.
> By
> your own words above "slave_sleep cannot start until master_sleep has
> been started" and master_sleep remained stopped.
>
> > If you want slave_sleep to also stop whenever master_sleep is
> > stopped,
> > then simply leave off the non-symmetrical -- the default behavior
> > is
> > what you want. When symmetrical, slave_sleep will be stopped before
> > stopping master_sleep (including if master_sleep fails).
> > 
> 
> No, that was not original question, sorry :)
> 
> > > > 
> > > > 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 

I misread ...

Given the constraint above, slave_sleep should never be started if
master_sleep is stopped. Feel free to open a bug at
bugs.clusterlabs.org with a crm_report attached.

> > > > 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
> > > 
> > > While I can answer your question (although gut feeling is that
> > > behavior
> > > is expected) - what is your final goal? If I interpret
> > > documentation
> > > correctly, the configuration with master target state "stop" and
> > > slave
> > > target state "start" makes it impossible to start slave at all.
> > > So
> > > while
> > > it may be interesting exercise, what are you trying to achieve at
> > > the
> > > end?
> > > 
> > > > - 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.
> > > > 
> > > 
> > > Actually my first reaction was "why slave was left started when
> > > master
> > > was stopped" :) If you do not question *this*, I'd say this
> > > behavior
> > > is
> > > logically correct - pacemaker tries to maintain status quo, and
> > > target
> > > state is "slave running" so it just tries to keep it running.
> > > 
> > > Whether slave should have been stopped when master had been
> > > stopped
> > > is
> > > interesting question; documentation is not exactly clear on
> > > semantic
> > > of
> > > Mandatory ordering constraints.
> > > 
> > > > 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
-- 
Ken Gaillot <kgaillot at redhat.com>