[Pacemaker] no-quorum-policy = demote?

[Christian Ciach]

Done:

http://bugs.clusterlabs.org/show_bug.cgi?id=5216

Best regards,
Christianc


2014-05-27 22:51 GMT+02:00 Andrew Beekhof <andrew at beekhof.net>:

>
> On 27 May 2014, at 7:20 pm, Christian Ciach <dereineda at gmail.com> wrote:
>
> >
> >
> >
> > 2014-05-27 7:34 GMT+02:00 Andrew Beekhof <andrew at beekhof.net>:
> >
> > On 27 May 2014, at 3:12 pm, Gao,Yan <ygao at suse.com> wrote:
> >
> > > 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.
> >
> > I guess the same logic applies to the single cluster use-case too and we
> should allow no-quorum-policy=demote.
> >
> >
> > Thank you for mentioning this. This was my thought as well.
> >
> > At the moment we "simulate" this behaviour by using a primitive resource
> where "started" means "master" and "stopped" means "slave". This way we can
> use "no-quorum-policy=stop" to actually switch the resource to slave on
> quorum loss. This seems hacky, so I would appreciate if this could be done
> in a proper way some time in the future.
>
> Could you file a bug for that in bugs.clusterlabs.org so we don't loose
> track of it?
>
> >
> > One question though... do we still stop non-master/slave resources for
> loss-policy=demote?
> >
> > >
> > > 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.
> > >
> > > _______________________________________________
> > > 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
> >
> >
> > _______________________________________________
> > 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: <http://oss.clusterlabs.org/pipermail/pacemaker/attachments/20140528/6277bd38/attachment-0001.html>