[Pacemaker] no-quorum-policy = demote?

[Gao,Yan]

On 05/27/14 08:07, Andrew Beekhof wrote:
> 
> On 26 May 2014, at 10:47 pm, Christian Ciach <dereineda at gmail.com> wrote:
> 
>> I am sorry to get back to this topic, but I'm genuinely curious:
>>
>> 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.
> 
> Or one feature too many.
> Perhaps Yan can explain why he wanted demote as an option for the loss-policy.
Loss-policy="demote" is a kind of natural default if the "Master" mode
of a resource requires a ticket like:
<rsc_ticket rsc="ms1" rsc-role="Master" ticket="ticketA"/>

The idea is for running stateful resource instances across clusters. And
loss-policy="demote" provides the possibility if there's the need to
still run the resource in slave mode for any reason when losing the
ticket, rather than stopping it or fencing the node hosting it.

Regards,
  Yan

> 
>>
>> Best regards
>> Christian
>>
>>
>> 2014-04-07 9:54 GMT+02:00 Christian Ciach <dereineda at gmail.com>:
>> Hello,
>>
>> I am using Corosync 2.0 with Pacemaker 1.1 on Ubuntu Server 14.04 (daily builds until final release).
>>
>> 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.
>>
>> 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.
>>
>> 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?
>>
>> 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?
>>
>>
>> _______________________________________________
>> 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
> 

-- 
Gao,Yan <ygao at suse.com>
Software Engineer
China Server Team, SUSE.