Thanks Ken. 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 ...). 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). Best Regards,Strahil Nikolov Sent from Yahoo Mail on Android On Mon, Jan 25, 2021 at 18:16, Ken Gaillot<kgail...@redhat.com> wrote: On Mon, 2021-01-25 at 13:22 +0100, Ulrich Windl wrote: > > > > Strahil Nikolov <hunter86...@yahoo.com> schrieb am 25.01.2021 > > > > um 12:28 in > > Nachricht <1768184755.3488991.1611574085...@mail.yahoo.com>: > > Hi All, > > As you all know migrating a resource is actually manipulating the > > location > > constraint for that resource. > > Is there any plan for an option to control a default timeout which > > is valid > > for migrations and will remove the 'cli-ban' and 'cli-preffer' > > location > > constraints automatically after the defined timeout ?
It's not a default, but the option has always been there: if you're using crm_resource --move/--ban, just add a --lifetime. Under the hood, it adds a time-based rule to the constraint (which you could do if you're explicitly adding a constraint yourself). Some people are bothered that the constraint itself remains in the configuration after it expires (it just has no effect anymore). A more recent option crm_resource --clear --expired will remove all expired constraints from the configuration. > I think the problem is the implementation: It's implemented like a > constraint, not like an action. > For an action it would be enough to send to the LRMs, while for a > constraint it has to be saved to the CIB. Pacemaker's scheduler is state-based rather than action-based. If all you did was an action, the scheduler would immediately want to revert it, to meet the desired state as expressed by the configuration. (Of course something like stickiness could be used to affect that, but the general principle remains: you have to tell the scheduler what end state you want, and let it decide what actions take you there.) > It would be preferable IMHO if those move contraints were not saved > in the CIB at all (as opposed to real location constraints). The CIB is the only input to the scheduler; everything defining the desired state has to be in there. User modifies CIB -> controller feeds CIB to scheduler -> scheduler gives back a list of actions that need to be done (if any) -> controller coordinates the execution of those actions If the scheduler thinks resource R should be on node N, then the CIB has to be changed to get it to change its mind. Otherwise it will want to move it back. If your goal is "I want R to run on N2", then that is in fact a location preference, which is expressed via a constraint. > But as things are now: Could the cluster recheck take care of those? > > > > > > > Best Regards,Strahil Nikolov > > Sent from Yahoo Mail on Android -- Ken Gaillot <kgail...@redhat.com>
_______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/