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