[ClusterLabs] location constraint does not move promoted resource ?

[Vladislav Bogdanov]

I think 10000 is a common number across promotable resource agents writers 
to pass to crm_master when agent during probe/monitor call thinks that node 
is really ready to have a resource promoted. Drbd is one of examples.

Best,
Vlad

lejeczek via Users <users at clusterlabs.org> 03.06.2023. 19:32:58 wrote:

> 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.
>
>
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users
>
> ClusterLabs home: https://www.clusterlabs.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20230703/85e5c903/attachment.htm>