Thank you for pointing me to the environment variables. Unfortunately, none of these work in this case. For example: Assume one node is currently the master. Then, because of a network failure, this node loses quorum. Because "no-quorum-policy" is set to "ignore", this node will keep being a master. In this case there is no change of state, thus the notify-function of the OCF-agent does not get called by pacemaker. I've already tried this, so I am quite sure about that.
2014-04-11 8:16 GMT+02:00 Alexandre <alxg...@gmail.com>: > > Le 10 avr. 2014 15:44, "Christian Ciach" <derein...@gmail.com> a écrit : > > > > > I don't really like the idea to periodically poll "crm_node -q" for the > current quorum state. No matter how frequently the monitor-function gets > called, there will always be a small time frame where both nodes will be in > the master state at the same time. > > > > Is there a way to get a notification to the OCF-agent whenever the > quorum state changes? > > You should probably look for something like this in the > ocfshellfunction.sh file. > > But also take a look at the page below, it has a lot of multi state > dedicated variables that are most definitely useful in your case. > > > http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/_multi_state_proper_interpretation_of_notification_environment_variables.html > > > > > > > 2014-04-08 10:14 GMT+02:00 Christian Ciach <derein...@gmail.com>: > > > >> Interesting idea! I can confirm that this works. So, I need to monitor > the output of "crm_node -q" to check if the current partition has quorum. > If the partition doesn't have quorum, I need to set the location constraint > according to your example. If the partition gets quorum again, I need to > remove the constraint. > >> > >> This seems almost a bit hacky, but it should work okay. Thank you! It > almost a shame that pacemaker doesn't have "demote" as a > "no-quorum-policy", but supports "demote" as a "loss-policy" for tickets. > >> > >> Yesterday I had another idea: Maybe I won't use a multistate resource > agent but a primitive instead. This way, I will start the resource outside > of pacemaker and let the start-action of the OCF-agent set the resource to > master and the stop-action sets it to slave. Then I will just use > "no-quorum-policy=stop". The downside of this is that I cannot distinguish > between a stopped resource and a resource in a slave state using crm_mon. > > > > > > > > _______________________________________________ > > Pacemaker mailing list: Pacemaker@oss.clusterlabs.org > > http://oss.clusterlabs.org/mailman/listinfo/pacemaker > > > > Project Home: http://www.clusterlabs.org > > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > > Bugs: http://bugs.clusterlabs.org > > > > > _______________________________________________ > Pacemaker mailing list: Pacemaker@oss.clusterlabs.org > http://oss.clusterlabs.org/mailman/listinfo/pacemaker > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org > >
_______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org