[ClusterLabs] Pacemaker ordering constraints and resource failures

[Andrei Borzenkov]

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 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
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list: Users at clusterlabs.org
>>> https://lists.clusterlabs.org/mailman/listinfo/users
>>>
>>> Project Home: http://www.clusterlabs.org
>>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratc
>>> h.pdf
>>> Bugs: http://bugs.clusterlabs.org
>>>
>>
>> _______________________________________________
>> Users mailing list: Users at clusterlabs.org
>> https://lists.clusterlabs.org/mailman/listinfo/users
>>
>> Project Home: http://www.clusterlabs.org
>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.
>> pdf
>> Bugs: http://bugs.clusterlabs.org