[Pacemaker] no-quorum-policy = demote?

[Christian Ciach]

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 <alxgomz at gmail.com>:

>
> Le 10 avr. 2014 15:44, "Christian Ciach" <dereineda at 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 <dereineda at 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 at 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 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20140411/0aff9fd4/attachment-0003.html>