Thanks Ken.<div id="yMail_cursorElementTracker_1611848498228"><br></div><div id="yMail_cursorElementTracker_1611848498782">The problem is that many junior admins forget about removing the constraint or using lifetime option (as it uses a not very common ISO format whete PT10M and P10M are easy to mistake and could lead to ...).</div><div id="yMail_cursorElementTracker_1611848615286"><br></div><div id="yMail_cursorElementTracker_1611848615514">Do you think that it is worth opening a RFE where admin can set a configuration that any migration lifetime is, by default,  '8 hours' ( for example) and afterwards it expires (just like with timeout).</div><div id="yMail_cursorElementTracker_1611848685823"><br></div><div id="yMail_cursorElementTracker_1611848686009">Best Regards,</div><div id="yMail_cursorElementTracker_1611848689898">Strahil Nikolov</div><div id="yMail_cursorElementTracker_1611848613370"><br><div id="ymail_android_signature"><a id="ymail_android_signature_link" href="https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature">Sent from Yahoo Mail on Android</a></div> <br> <blockquote style="margin: 0 0 20px 0;"> <div style="font-family:Roboto, sans-serif; color:#6D00F6;"> <div>On Mon, Jan 25, 2021 at 18:16, Ken Gaillot</div><div><kgaillot@redhat.com> wrote:</div> </div> <div style="padding: 10px 0 0 20px; margin: 10px 0 0 0; border-left: 1px solid #6D00F6;"> On Mon, 2021-01-25 at 13:22 +0100, Ulrich Windl wrote:<br clear="none">> > > > Strahil Nikolov <<a shape="rect" ymailto="mailto:hunter86_bg@yahoo.com" href="mailto:hunter86_bg@yahoo.com">hunter86_bg@yahoo.com</a>> schrieb am 25.01.2021<br clear="none">> > > > um 12:28 in<br clear="none">> <br clear="none">> Nachricht <<a shape="rect" ymailto="mailto:1768184755.3488991.1611574085647@mail.yahoo.com" href="mailto:1768184755.3488991.1611574085647@mail.yahoo.com">1768184755.3488991.1611574085647@mail.yahoo.com</a>>:<br clear="none">> > Hi All,<br clear="none">> > As you all know migrating a resource is actually manipulating the<br clear="none">> > location <br clear="none">> > constraint for that resource.<br clear="none">> > Is there any plan for an option to control a default timeout which<br clear="none">> > is valid <br clear="none">> > for migrations and will remove the 'cli-ban' and 'cli-preffer'<br clear="none">> > location <br clear="none">> > constraints automatically after the defined timeout ?<br clear="none"><br clear="none">It's not a default, but the option has always been there: if you're<br clear="none">using crm_resource --move/--ban, just add a --lifetime. Under the hood,<br clear="none">it adds a time-based rule to the constraint (which you could do if<br clear="none">you're explicitly adding a constraint yourself).<br clear="none"><br clear="none">Some people are bothered that the constraint itself remains in the<br clear="none">configuration after it expires (it just has no effect anymore). A more<br clear="none">recent option crm_resource --clear --expired will remove all expired<br clear="none">constraints from the configuration.<br clear="none"><br clear="none"><br clear="none">> I think the problem is the implementation: It's implemented like a<br clear="none">> constraint, not like an action.<br clear="none">> For an action it would be enough to send to the LRMs, while for a<br clear="none">> constraint it has to be saved to the CIB.<br clear="none"><br clear="none">Pacemaker's scheduler is state-based rather than action-based. If all<br clear="none">you did was an action, the scheduler would immediately want to revert<br clear="none">it, to meet the desired state as expressed by the configuration. (Of<br clear="none">course something like stickiness could be used to affect that, but the<br clear="none">general principle remains: you have to tell the scheduler what end<br clear="none">state you want, and let it decide what actions take you there.)<br clear="none"><br clear="none">> It would be preferable IMHO if those  move contraints were not saved<br clear="none">> in the CIB at all (as opposed to real location constraints).<br clear="none"><br clear="none">The CIB is the only input to the scheduler; everything defining the<br clear="none">desired state has to be in there.<br clear="none"><br clear="none">User modifies CIB -> controller feeds CIB to scheduler -> scheduler<br clear="none">gives back a list of actions that need to be done (if any) -><br clear="none">controller coordinates the execution of those actions<br clear="none"><br clear="none">If the scheduler thinks resource R should be on node N, then the CIB<br clear="none">has to be changed to get it to change its mind. Otherwise it will want<br clear="none">to move it back. If your goal is "I want R to run on N2", then that is<br clear="none">in fact a location preference, which is expressed via a constraint.<div class="yqt2026088149" id="yqtfd87288"><br clear="none"><br clear="none">> But as things are now: Could the cluster recheck take care of those?<br clear="none">> <br clear="none">> > <br clear="none">> > <br clear="none">> > Best Regards,Strahil Nikolov<br clear="none">> > Sent from Yahoo Mail on Android</div><br clear="none">-- <br clear="none">Ken Gaillot <<a shape="rect" ymailto="mailto:kgaillot@redhat.com" href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a><div class="yqt2026088149" id="yqtfd67261">><br clear="none"><br clear="none"></div> </div> </blockquote></div>