[ClusterLabs] location constraint does not move promoted resource ?

[Ken Gaillot]

On Mon, 2023-07-03 at 19:22 +0300, Andrei Borzenkov wrote:
> On 03.07.2023 18:07, Ken Gaillot wrote:
> > On Mon, 2023-07-03 at 12:20 +0200, lejeczek via Users wrote:
> > > On 03/07/2023 11:16, Andrei Borzenkov wrote:
> > > > On 03.07.2023 12:05, lejeczek via Users wrote:
> > > > > Hi guys.
> > > > > 
> > > > > I have pgsql with I constrain like so:
> > > > > 
> > > > > -> $ pcs constraint location PGSQL-clone rule role=Promoted
> > > > > score=-1000 gateway-link ne 1
> > > > > 
> > > > > and I have a few more location constraints with that
> > > > > ethmonitor & those work, but this one does not seem to.
> > > > > When contraint is created cluster is silent, no errors nor
> > > > > warning, but relocation does not take place.
> > > > > I can move promoted resource manually just fine, to that
> > > > > node where 'location' should move it.
> > > > > 
> > > > 
> > > > Instance to promote is selected according to promotion
> > > > scores which are normally set by resource agent.
> > > > Documentation implies that standard location constraints
> > > > are also taken in account, but there is no explanation how
> > > > promotion scores interoperate with location scores. It is
> > > > possible that promotion score in this case takes precedence.
> > > It seems to have kicked in with score=-10000 but..
> > > that was me just guessing.
> > > Indeed it would be great to know how those are calculated,
> > > in a way which would' be admin friendly or just obvious.
> > > 
> > > thanks, L.
> > 
> > It's a longstanding goal to have some sort of tool for explaining
> > how
> > scores interact in a given situation. However it's a challenging
> > problem and there's never enough time ...
> > 
> > Basically, all scores are added together for each node, and the
> > node
> > with the highest score runs the resource, subject to any placement
> > strategy configured. These mainly include stickiness, location
> > constraints, colocation constraints, and node health. Nodes may be
> 
> And you omitted the promotion scores which was the main question.

Oh right -- first, the above is used to determine the nodes on which
clone instances will be placed. After that, an appropriate number of
nodes are selected for the promoted role, based on promotion scores and
location and colocation constraints for the promoted role.

When colocations are considered, chained colocations are considered at
an attenuated score. If A is colocated with B, and B is colocated with
C, A's preferences are considered when assigning C to a node, but at
less than full strength. That's one of the reasons it gets complicated
to figure out a particular situation.

> > eliminated from consideration by resource migration thresholds,
> > standby/maintenance mode, etc.
-- 
Ken Gaillot <kgaillot at redhat.com>