08.08.2018 07:36, Andrei Borzenkov пишет:
> 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 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

s/can/can not/

Sorry :)

> (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: [email protected]
>> 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
>>
> 

_______________________________________________
Users mailing list: [email protected]
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

Reply via email to