[ClusterLabs] Antw: [EXT] Resource migration and constraint timeout

[Strahil Nikolov]

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<kgaillot at redhat.com> wrote:   On Mon, 2021-01-25 at 13:22 +0100, Ulrich Windl wrote:
> > > > Strahil Nikolov <hunter86_bg at yahoo.com> schrieb am 25.01.2021
> > > > um 12:28 in
> 
> Nachricht <1768184755.3488991.1611574085647 at 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 <kgaillot at redhat.com>

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clusterlabs.org/pipermail/users/attachments/20210128/823303e0/attachment-0001.htm>