On Mon, Feb 5, 2024 at 12:44 PM lejeczek via Users <users@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. _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
