<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 24 May 2016, at 2:23 AM, Alex Lyakas <<a href="mailto:alex@zadarastorage.com" class="">alex@zadarastorage.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hello Andrew,<br class=""><br class="">We have a system in the field running a MASTER-SLAVE resource on two nodes. We are trying to upgrade the pacemaker on these two nodes. First we upgrade the SLAVE node. Then we move the resource to be MASTER on the upgraded SLAVE node (“crm node standby” on the old MASTER). This move involves cancelling a monitor operation on the SLAVE node.<br class=""><br class="">With commit<br class=""><a href="https://github.com/ClusterLabs/pacemaker/commit/abcdaa8893d6071574986af6abc85ae558473735" class="">https://github.com/ClusterLabs/pacemaker/commit/abcdaa8893d6071574986af6abc85ae558473735</a><br class="">there is a change of how the “cancel” action is confirmed.<br class=""><br class="">Previously, send_direct_ack was always used to confirm the cancel action. But now, the cancel action is being confirmed not by direct ACK but by parsing the XML.<br class=""></div></div></blockquote><div><br class=""></div><div>Oh, and you’re mixing pacemaker versions.</div><div>I can see how that would be a problem.</div><div><br class=""></div><div>Are you seeing this in the process of upgrading the entire cluster is the plan just to update one?</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">So the new node receives the cancel action, but doesn’t call send_direct_ack. As a result on the old node, it sends the cancel action:<br class="">May 23 18:05:49 vsa-000001be-vc-0 crmd: [3089]: info: te_rsc_command: Initiating action 4: cancel VAM:1_monitor_5000 on vsa-000001be-vc-1<br class=""><br class="">And after 3 minutes only it moves forward due to timeout<br class="">May 23 18:08:49 vsa-000001be-vc-0 crmd: [3089]: WARN: action_timer_callback: Timer popped (timeout=120000, abort_level=1000000, complete=false)<br class="">May 23 18:08:49 vsa-000001be-vc-0 crmd: [3089]: ERROR: print_elem: Aborting transition, action lost: [Action 4]: In-flight (id: VAM:1_monitor_5000, loc: vsa-000001be-vc-1, priority: 0)<br class="">May 23 18:08:49 vsa-000001be-vc-0 crmd: [3089]: info: abort_transition_graph: action_timer_callback:512 - Triggered transition abort (complete=0) : Action lost<br class=""><br class="">However, the 3 minute-timeout is unacceptable for our customers.<br class=""><br class="">What would you recommend to fix this backward compatibility issue?<br class=""></div></div></blockquote><div><br class=""></div><div>Unfortunately, you might need to resort to the detach+upgrade everything+reattach method of upgrading as described here:</div><div><br class=""></div><div> <a href="http://clusterlabs.org/doc/en-US/Pacemaker/1.1-plugin/html/Pacemaker_Explained/_disconnect_and_reattach.html" class="">http://clusterlabs.org/doc/en-US/Pacemaker/1.1-plugin/html/Pacemaker_Explained/_disconnect_and_reattach.html</a></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Only as a test, I called send_direct_ack in case “in_progress==TRUE” also. This fixed the problem, as the older node received the needed ACK. But I don’t know what this change might break.<br class=""></div></div></blockquote><div><br class=""></div><div>It would probably be fine as a transition plan.</div><div>Ie. first do a rolling update to the patched version, then another to the unpatched version.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Thanks,<br class="">Alex.<br class=""><br class=""><br class=""><br class=""><br class=""><br class=""></div></div></blockquote></div><br class=""></body></html>