[ClusterLabs] colocation constraint - do I get it all wrong?

[Andrei Borzenkov]

On Mon, Feb 5, 2024 at 12:44 PM lejeczek via Users
<users at clusterlabs.org> wrote:
>
>
>
> On 01/01/2024 18:28, Ken Gaillot wrote:
> > On Fri, 2023-12-22 at 17:02 +0100, lejeczek via Users wrote:
> >> hi guys.
> >>
> >> I have a colocation constraint:
> >>
> >> -> $ pcs constraint ref DHCPD
> >> Resource: DHCPD
> >>    colocation-DHCPD-GATEWAY-NM-link-INFINITY
> >>
> >> and the trouble is... I thought DHCPD is to follow GATEWAY-NM-link,
> >> always!
> >> If that is true that I see very strange behavior, namely.
> >> When there is an issue with DHCPD resource, cannot be started, then
> >> GATEWAY-NM-link gets tossed around by the cluster.
> >>
> >> Is that normal & expected - is my understanding of _colocation_
> >> completely wrong - or my cluster is indeed "broken"?
> >> many thanks, L.
> >>
> > Pacemaker considers the preferences of colocated resources when
> > assigning a resource to a node, to ensure that as many resources as
> > possible can run. So if a colocated resource becomes unable to run on a
> > node, the primary resource might move to allow the colocated resource
> > to run.
> So what is the way to "fix" this - is it simply low/er score
> for such constraint?
> In my case _dhcpd_ is important but if fails sometimes as
> it's often tampered with, so... make _dhcpd_ flow
> gateway_link but just fail _dhcp_ (it it keeps failing) and
> leave _gateway_link_ alone if/where it's good.
> Or perhaps there a global config/param for whole cluster
> behaviour?
>

In the current pacemaker (since 2.1.0) you can set "influence"
colocation attribute to avoid moving already started resource:

However, if influence is set to false in the colocation constraint,
this will happen only if B is inactive and needing to be started. If B
is already active, A’s preferences will have no effect on placing B.