[ClusterLabs] Antw: Re: Antw: Changes coming in Pacemaker 2.0.0

[Jehan-Guillaume de Rorthais]

On Thu, 11 Jan 2018 18:32:35 +0300
Andrei Borzenkov <arvidjaar at gmail.com> wrote:

> On Thu, Jan 11, 2018 at 2:52 PM, Ulrich Windl
> <Ulrich.Windl at rz.uni-regensburg.de> wrote:
> >
> >  
> >>>> Andrei Borzenkov <arvidjaar at gmail.com> schrieb am 11.01.2018 um 12:41
> >>>> in  
> > Nachricht
> > <CAA91j0WAOQg46434gVvz_8Yw5VE09FQHshQp-vQjo7uV6fezbA at mail.gmail.com>:  
> >> On Thu, Jan 11, 2018 at 10:54 AM, Ulrich Windl
> >> <Ulrich.Windl at rz.uni-regensburg.de> wrote:  
> >>> Hi!
> >>>
> >>> On the tool changes, I'd prefer --move and --un-move as pair over --move
> >>> and --clear  
> >> ("clear" is less expressive IMHO).
> >>
> >> --un-move is really wrong semantically. You do not "unmove" resource -
> >> you "clear" constraints that were created. Whether this actually
> >> results in any "movement" is unpredictable (easily).  
> >
> > You undo what "move" does: "un-move". With your argument, "move" is just as
> > bad: Why not "--forbid-host" and "--allow-host" then? 
> 
> That would be less confusing as it sounds more declarative and matches
> what actually happens - setting configuration parameter instead of
> initiating some action.

For what is worth, while using crmsh, I always have to explain to
people or customers that:

* we should issue an "unmigrate" to remove the constraint as soon as the
  resource can get back to the original node or get off the current node if
  needed (depending on the -inf or +inf constraint location issued)
* this will not migrate back the resource if it's sticky enough on the current
  node. 

See:
http://clusterlabs.github.io/PAF/Debian-8-admin-cookbook.html#swapping-master-and-slave-roles-between-nodes

This is counter-intuitive, indeed. I prefer the pcs interface using
the move/clear actions.