<html><body><p>Ken, <br><br>Thanks for the explanation. <br><br>One other thing, relating to the iface-bridge resource creation. I specified --disabled flag: <br><br><tt>> [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" --</tt><tt><b>disabled</b></tt><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><img width="16" height="16" src="cid:1__=8FBB0A2FDFFD78208f9e8a93df938690918c8FB@" border="0" 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 color="#424282">Ken Gaillot ---02/02/2017 03:29:12 PM---On 02/02/2017 02:14 PM, Scott Greenlese wrote: > Hi folks,</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Ken Gaillot <kgaillot@redhat.com></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">users@clusterlabs.org</font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">02/02/2017 03:29 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><tt>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<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><br></tt><br><br><BR>
</body></html>