[ClusterLabs] location constraint does not move promoted resource ?

[Andrei Borzenkov]

On 03.07.2023 19:39, Ken Gaillot wrote:
> 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.
> 

I am sorry but it does not really explain anything. Let's try concrete 
examples

a) master clone instance has location score -1000 for a node and 
promotion score 1000. Is this node eligible for promoting clone instance 
(assuming no other scores are present)?

b) promotion score is equal on two nodes A and B, but node A has better 
location score than node B. Is it guaranteed that clone will be promoted 
on A?

> 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.