On Wed, Mar 12, 2014 at 12:37 AM, Andrew Beekhof <and...@beekhof.net> wrote:
> It was put in when drbd called:
>
> fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
>
> When and why it called that is not my area of expertise though.
>
The constraint put by crm-fence-peer.sh was
<rsc_location rsc="ms_OvirtData"
id="drbd-fence-by-handler-
ovirt-ms_OvirtData">
<rule role="Master" score="-INFINITY"
id="drbd-fence-by-handler-ovirt-rule-ms_OvirtData">
<expression attribute="#uname" operation="ne"
value="ovirteng02.localdomain.
local"
id="drbd-fence-by-handler-ovirt-expr-ms_OvirtData"/>
and I think it was good, in the sense that from now on only ovirteng02
could start the drbd resource, as ovirteng01 was fenced.
But the problem actually was the other constraint
<rsc_location id="cli-ban-ovirt-on-
ovirteng02.localdomain.local"
rsc="ovirt" role="Started" node="ovirteng02.localdomain.local"
score="-INFINITY"/>
preventing ovirteng02 from running ovirt group.
Going backward in the logs I see that the constraint was put 2 days
before during my previous tests (I find it in pe-input-1066.bz2)
And if I reproduce now a "pcs resource move ovirt" I see that the same
constraint is put inside..... and it is removed as I run "pcs resource
clear ovirt" (I can run it on any node, not necessarily the one where
i ran the move operation)
Gianluca
_______________________________________________
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
