<html><body><p>Further explanation for my concern about --disabled not taking effect until after the iface-bridge was configured ...<br><br>The reason I wanted to create the iface-bridge resource "disabled", was to allow me the opportunity to impose<br>a location constraint / rule on the resource to prevent it from being started on certain cluster nodes, <br>where the specified slave vlan did not exist. <br><br>In my case, pacemaker assigned the resource to a cluster node where the specified slave vlan did not exist, which in turn <br>triggered a fenced (off) action against that node (apparently, because the device could not be stopped, per Ken's reply earlier). <br><br>Again, my cluster is configured as "symmetric" , so I would have to "opt out" my new resource from<br>certain cluster nodes via location constraint. <br><br>So, if this really is how --disable is designed to work, is there any way to impose a location constraint rule BEFORE <br>the iface-bridge resource gets assigned. configured and started on a cluster node in a symmetrical cluster? <br><br>Thanks, <br><br>Scott Greenlese ... IBM KVM on System Z - Solutions Test, Poughkeepsie, N.Y.<br> INTERNET: swgreenl@us.ibm.com <br><br><br><br><img width="16" height="16" src="cid:1__=8FBB0A2CDFC3677A8f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for Scott Greenlese---02/03/2017 03:23:40 PM---Ken, Thanks for the explanation."><font color="#424282">Scott Greenlese---02/03/2017 03:23:40 PM---Ken, Thanks for the explanation.</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Scott Greenlese/Poughkeepsie/IBM@IBMUS</font><br><font size="2" color="#5F5F5F">To: </font><font size="2">kgaillot@redhat.com, Cluster Labs - All topics related to open-source clustering welcomed <users@clusterlabs.org></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">02/03/2017 03:23 PM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [ClusterLabs] Failure to configure iface-bridge resource causes cluster node fence action.</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><font size="4">Ken, <br><br>Thanks for the explanation. <br><br>One other thing, relating to the iface-bridge resource creation. I specified --disabled flag: <br></font><tt><font size="4"><br>> [root@zs95kj VD]# date;pcs resource create br0_r1<br>> ocf:heartbeat:iface-bridge bridge_name=br0 bridge_slaves=vlan1292 op<br>> monitor timeout="20s" interval="10s" --</font></tt><tt><b><font size="4">disabled</font></b></tt><font size="4"><br><br>Does the bridge device have to be successfully configured by pacemaker before disabling the resource? It seems<br>that that was the behavior, since it failed the resource and fenced the node instead of disabling the resource. <br>Just checking with you to be sure. <br><br>Thanks again..<br><br>Scott Greenlese ... IBM KVM on System Z Solutions Test, Poughkeepsie, N.Y.<br>INTERNET: swgreenl@us.ibm.com <br><br><br><br></font><img src="cid:1__=8FBB0A2CDFC3677A8f9e8a93df938690918c8FB@" width="16" height="16" alt="Inactive hide details for Ken Gaillot ---02/02/2017 03:29:12 PM---On 02/02/2017 02:14 PM, Scott Greenlese wrote: > Hi folks,"><font size="4" color="#424282">Ken Gaillot ---02/02/2017 03:29:12 PM---On 02/02/2017 02:14 PM, Scott Greenlese wrote: > Hi folks,</font><font size="4"><br></font><font color="#5F5F5F"><br>From: </font>Ken Gaillot <kgaillot@redhat.com><font color="#5F5F5F"><br>To: </font>users@clusterlabs.org<font color="#5F5F5F"><br>Date: </font>02/02/2017 03:29 PM<font color="#5F5F5F"><br>Subject: </font>Re: [ClusterLabs] Failure to configure iface-bridge resource causes cluster node fence action.<font size="4"><br></font><hr width="100%" size="2" align="left" noshade><font size="4"><br><br></font><tt><font size="4"><br>On 02/02/2017 02:14 PM, Scott Greenlese wrote:<br>> Hi folks,<br>> <br>> I'm testing iface-bridge resource support on a Linux KVM on System Z<br>> pacemaker cluster.<br>> <br>> pacemaker-1.1.13-10.el7_2.ibm.1.s390x<br>> corosync-2.3.4-7.el7_2.ibm.1.s390x<br>> <br>> I created an iface-bridge resource, but specified a non-existent<br>> bridge_slaves value, vlan1292 (i.e. vlan1292 doesn't exist).<br>> <br>> [root@zs95kj VD]# date;pcs resource create br0_r1<br>> ocf:heartbeat:iface-bridge bridge_name=br0 bridge_slaves=vlan1292 op<br>> monitor timeout="20s" interval="10s" --disabled<br>> Wed Feb 1 17:49:16 EST 2017<br>> [root@zs95kj VD]#<br>> <br>> [root@zs95kj VD]# pcs resource show |grep br0<br>> br0_r1 (ocf::heartbeat:iface-bridge): FAILED zs93kjpcs1<br>> [root@zs95kj VD]#<br>> <br>> As you can see, the resource was created, but failed to start on the<br>> target node zs93kppcs1.<br>> <br>> To my surprise, the target node zs93kppcs1 was unceremoniously fenced.<br>> <br>> pacemaker.log shows a fence (off) action initiated against that target<br>> node, "because of resource failure(s)" :<br>> <br>> Feb 01 17:55:56 [52941] zs95kj crm_resource: ( unpack.c:2719 ) debug:<br>> determine_op_status: br0_r1_stop_0 on zs93kjpcs1 returned 'not<br>> configured' (6) instead of the expected value: 'ok' (0)<br>> Feb 01 17:55:56 [52941] zs95kj crm_resource: ( unpack.c:2602 ) warning:<br>> unpack_rsc_op_failure: Processing failed op stop for br0_r1 on<br>> zs93kjpcs1: not configured (6)<br>> Feb 01 17:55:56 [52941] zs95kj crm_resource: ( unpack.c:3244 ) error:<br>> unpack_rsc_op: Preventing br0_r1 from re-starting anywhere: operation<br>> stop failed 'not configured' (6)<br>> Feb 01 17:55:56 [52941] zs95kj crm_resource: ( unpack.c:2719 ) debug:<br>> determine_op_status: br0_r1_stop_0 on zs93kjpcs1 returned 'not<br>> configured' (6) instead of the expected value: 'ok' (0)<br>> Feb 01 17:55:56 [52941] zs95kj crm_resource: ( unpack.c:2602 ) warning:<br>> unpack_rsc_op_failure: Processing failed op stop for br0_r1 on<br>> zs93kjpcs1: not configured (6)<br>> Feb 01 17:55:56 [52941] zs95kj crm_resource: ( unpack.c:3244 ) error:<br>> unpack_rsc_op: Preventing br0_r1 from re-starting anywhere: operation<br>> stop failed 'not configured' (6)<br>> Feb 01 17:55:56 [52941] zs95kj crm_resource: ( unpack.c:96 ) warning:<br>> pe_fence_node: Node zs93kjpcs1 will be fenced because of resource failure(s)<br>> <br>> <br>> Thankfully, I was able to successfully create a iface-bridge resource<br>> when I changed the bridge_slaves value to an existent vlan interface.<br>> <br>> My main concern is, why would the response to a failed bridge config<br>> operation warrant a node fence (off) action? Isn't it enough to just<br>> fail the resource and try another cluster node,<br>> or at most, give up if it can't be started / configured on any node?<br>> <br>> Is there any way to control this harsh recovery action in the cluster?<br>> <br>> Thanks much..<br>> <br>> <br>> Scott Greenlese ... IBM KVM on System Z Solutions Test, Poughkeepsie, N.Y.<br>> INTERNET: swgreenl@us.ibm.com<br><br>It's actually the stop operation failure that leads to the fence.<br><br>If a resource fails to stop, fencing is the only way pacemaker can<br>recover the resource elsewhere. Consider a database master -- if it<br>doesn't stop, starting the master elsewhere could lead to severe data<br>inconsistency.<br><br>You can tell pacemaker to not attempt recovery, by setting on-fail=block<br>on the stop operation, so it doesn't need to fence. Obviously, that<br>prevents high availability, as manual intervention is required to do<br>anything further with the service.<br><br>_______________________________________________<br>Users mailing list: Users@clusterlabs.org</font></tt><tt><u><font size="4" color="#0000FF"><br></font></u></tt><a href="http://lists.clusterlabs.org/mailman/listinfo/users"><tt><u><font size="4" color="#0000FF">http://lists.clusterlabs.org/mailman/listinfo/users</font></u></tt></a><tt><font size="4"><br><br>Project Home: </font></tt><a href="http://www.clusterlabs.org/"><tt><u><font size="4" color="#0000FF">http://www.clusterlabs.org</font></u></tt></a><tt><font size="4"><br>Getting started: </font></tt><a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf"><tt><u><font size="4" color="#0000FF">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</font></u></tt></a><tt><font size="4"><br>Bugs: </font></tt><a href="http://bugs.clusterlabs.org/"><tt><u><font size="4" color="#0000FF">http://bugs.clusterlabs.org</font></u></tt></a><tt><font size="4"><br></font></tt><font size="4"><br><br><br></font><tt>_______________________________________________<br>Users mailing list: Users@clusterlabs.org<br></tt><tt><a href="http://lists.clusterlabs.org/mailman/listinfo/users">http://lists.clusterlabs.org/mailman/listinfo/users</a></tt><tt><br><br>Project Home: </tt><tt><a href="http://www.clusterlabs.org">http://www.clusterlabs.org</a></tt><tt><br>Getting started: </tt><tt><a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a></tt><tt><br>Bugs: </tt><tt><a href="http://bugs.clusterlabs.org">http://bugs.clusterlabs.org</a></tt><tt><br></tt><br><br><BR>
</body></html>