[ClusterLabs] location constraint does not move promoted resource ?

[lejeczek]

On 03/07/2023 18:55, Andrei Borzenkov wrote:
> 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?
>
>
a real-life example:
...Colocation Constraints:
   Started resource 'HA-10-1-1-253' with Promoted resource 
'PGSQL-clone' (id:
       colocation-HA-10-1-1-253-PGSQL-clone-INFINITY)
     score=INFINITY
..
Order Constraints:
   promote resource 'PGSQL-clone' then start resource 
'HA-10-1-1-253' (id: order-
       PGSQL-clone-HA-10-1-1-253-Mandatory)
     symmetrical=0 kind=Mandatory
   demote resource 'PGSQL-clone' then stop resource 
'HA-10-1-1-253' (id: order-
       PGSQL-clone-HA-10-1-1-253-Mandatory-1)
     symmetrical=0 kind=Mandatory

I had to bump this one up to:
...
   resource 'PGSQL-clone' (id: location-PGSQL-clone)
     Rules:
       Rule: role=Promoted score=-10000 (id: 
location-PGSQL-clone-rule)
         Expression: gateway-link ne 1 (id: 
location-PGSQL-clone-rule-expr)


'-1000' did not seem to be good enough, '-10000' was just a 
"lucky" guess.

as earlier: I was able to 'move' the promoted and I think 
'prefers' also worked.
I don't know it 'pgsql' would work with any other 
constraints, if it was safe to try so.

many thanks, L.