<div dir="ltr"><div><div>I am sorry to get back to this topic, but I'm genuinely curious:<br><br></div>Why is "demote" an option for the ticket "loss-policy" for multi-site-clusters but not for the normal "no-quorum-policy" of local clusters? This seems like a missing feature to me.<br>
<br></div><div>Best regards<br>Christian<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-04-07 9:54 GMT+02:00 Christian Ciach <span dir="ltr"><<a href="mailto:dereineda@gmail.com" target="_blank">dereineda@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello,<br><br></div><div>I am using Corosync 2.0 with Pacemaker 1.1 on Ubuntu Server 14.04 (daily builds until final release).<br>
<br></div><div>My problem is as follows: I have a 2-node (plus a quorum-node) cluster to manage a multistate-resource. One node should be the master and the other one the slave. It is absolutely not allowed to have two masters at the same time. To prevent a split-brain situation, I am also using a third node as a quorum-only node (set to standby). There is no redundant connection because the nodes are connected over the internet.<br>

<br></div><div>If one of the two nodes managing the resource becomes disconnected, it loses quorum. In this case, I want this resource to become a slave, but the resource should never be stopped completely! This leaves me with a problem: "no-quorum-policy=stop" will stop the resource, while "no-quorum-policy=ignore" will keep this resource in a master-state. I already tried to demote the resource manually inside the monitor-action of the OCF-agent, but pacemaker will promote the resource immediately again.<br>

<br></div><div>I am aware that I am trying the manage a multi-site-cluster and there is something like the booth-daemon, which sounds like the solution to my problem. But unfortunately I need the location-constraints of pacemaker based on the score of the OCF-agent. As far as I know location-constraints are not possible when using booth, because the 2-node-cluster is essentially split into two 1-node-clusters. Is this correct?<br>

<br></div><div>To conclude: Is it possible to demote a resource on quorum loss instead of stopping it? Is booth an option if I need to manage the location of the master based on the score returned by the OCF-agent?<br></div>

<div><br></div></div>
</blockquote></div><br></div>