Re: [ClusterLabs] Moving resource only one way
Yep, just set the stickiness to something bigger than '0' (max is INFINITY -> 100) Best Regards,Strahil Nikolov On Thu, Jul 15, 2021 at 15:02, Ervin Hegedüs wrote: Hi there, I have to build a very simple cluster with only one resource: a virtual IP. The "challenge":* there are two nodes in the cluster: primary and secondary* if primary node failed, secondary brings up the interface with the virtual IP* BUT: if the primary come back again, the resource must to stay on the secondary Is there any way to solve this? # crm --version crm 4.0.0 Thanks, a. ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/ ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
[ClusterLabs] FYI: regression in crm_attribute/crm_master/crm_failcount in 2.1.0
Hi all, Thanks to PAF users for testing and finding a regression in crm_attribute (and its crm_master and crm_failcount wrappers) in the recent 2.1.0 release. (CLBZ#5480) (1) Setting a negative attribute value doesn't work (e.g. "crm_attribute -n myattr -v -1000") (2) --get-value (a deprecated alias for --query) wrongly requires an (ignored) argument to be specified We'll do a fix and 2.1.1 release soon. -- Ken Gaillot ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] pcs stonith update problems
On 2021-07-16 10:48 a.m., kgail...@redhat.com wrote: > On Thu, 2021-07-15 at 18:02 -0400, Digimer wrote: >> Hi all, >> >> I've got a predicament... I want to update a stonith resource to >> remove an argument. Specifically, when resource move nodes, I want to >> change the stonith delay to favour the new host. This involves adding >> the 'delay="x"' argument to one stonith resource, and removing it >> from >> the other; > > There are two better ways to do what you want that don't involve > changing the configuration every time. > > (1) Priority fencing delay: > > https://clusterlabs.org/pacemaker/doc/2.1/Pacemaker_Explained/singlehtml/index.html#cluster-options > > This was added in 2.0.4, and does exactly what you want. Just set the > priority meta-attribute on your resources, and the priority-fencing- > delay cluster property. > > (1) Attribute-based rules: > > https://clusterlabs.org/pacemaker/doc/2.1/Pacemaker_Explained/singlehtml/index.html#document-rules > > If you don't have 2.0.4, you can use rules instead. pcs might not > support it, though, so you might need to configure the XML. > > * Configure an ocf:pacemaker:attribute resource that's colocated with > your main resource (this just sets a node attribute wherever it's > active) > > * Configure the stonith delay in a rule-based attribute block, with a 0 > delay if the node attribute is "active" and a higher delay if it's > "inactive" Welp, this could have saved me a LOT of time, had I known. Haha! Thanks! -- Digimer Papers and Projects: https://alteeve.com/w/ "I am, somehow, less interested in the weight and convolutions of Einstein’s brain than in the near certainty that people of equal talent have lived and died in cotton fields and sweatshops." - Stephen Jay Gould ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] pcs stonith update problems
On Thu, 2021-07-15 at 18:02 -0400, Digimer wrote: > Hi all, > > I've got a predicament... I want to update a stonith resource to > remove an argument. Specifically, when resource move nodes, I want to > change the stonith delay to favour the new host. This involves adding > the 'delay="x"' argument to one stonith resource, and removing it > from > the other; There are two better ways to do what you want that don't involve changing the configuration every time. (1) Priority fencing delay: https://clusterlabs.org/pacemaker/doc/2.1/Pacemaker_Explained/singlehtml/index.html#cluster-options This was added in 2.0.4, and does exactly what you want. Just set the priority meta-attribute on your resources, and the priority-fencing- delay cluster property. (1) Attribute-based rules: https://clusterlabs.org/pacemaker/doc/2.1/Pacemaker_Explained/singlehtml/index.html#document-rules If you don't have 2.0.4, you can use rules instead. pcs might not support it, though, so you might need to configure the XML. * Configure an ocf:pacemaker:attribute resource that's colocated with your main resource (this just sets a node attribute wherever it's active) * Configure the stonith delay in a rule-based attribute block, with a 0 delay if the node attribute is "active" and a higher delay if it's "inactive" > Example; > > > # pcs cluster cib | grep -B7 -A7 '"delay"' >type="fence_ipmilan"> > >name="ipaddr" value="10.201.17.1"/> >name="password" value="xxx"/> >name="pcmk_host_list" value="an-a02n01"/> >name="username" value="admin"/> >name="delay" value="15"/> > > >name="monitor"/> > > > > > Here, the stonith resource 'ipmilan_node1' has the delay="15". > > If I run: > > > # pcs stonith update ipmilan_node1 fence_ipmilan ipaddr="10.201.17.1" > password="xxx" username="admin"; echo $? > 0 > > > I see nothing happen in journald, and the delay argument remains in > the > 'pcs cluster cib' output. If, however, I do; > > > # /usr/sbin/pcs stonith update ipmilan_node1 fence_ipmilan > ipaddr="10.201.17.1" password="xxx" username="admin" delay="0"; echo > $? > 0 > > > I can see in journald that the CIB was updated and can confirm in > 'pcs > cluster cib' that the 'delay' value becomes '0'. So it seems that, if > an > argument previously existed and is NOT specified in an update, it is > not > removed. > > Is this intentional for some reason? If so, how would I remove the > delay > attribute? I've got a fairly complex stonith config, with stonith > levels. Deleting and recreating the config would be non-trivial. > > Pacemaker v2.1.0, pcs v0.10.8.181-47e9, CentOS Stream 8. > > digimer > -- Ken Gaillot ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] pcs stonith update problems
On 2021-07-16 9:26 a.m., Tomas Jelinek wrote: > Dne 16. 07. 21 v 6:35 Andrei Borzenkov napsal(a): >> On 16.07.2021 01:02, Digimer wrote: >>> Hi all, >>> >>> I've got a predicament... I want to update a stonith resource to >>> remove an argument. Specifically, when resource move nodes, I want to >>> change the stonith delay to favour the new host. This involves adding >>> the 'delay="x"' argument to one stonith resource, and removing it from >>> the other; >>> >>> Example; >>> >>> >>> # pcs cluster cib | grep -B7 -A7 '"delay"' >>> >> type="fence_ipmilan"> >>> >>> >> name="ipaddr" value="10.201.17.1"/> >>> >> name="password" value="xxx"/> >>> >> name="pcmk_host_list" value="an-a02n01"/> >>> >> name="username" value="admin"/> >>> >> name="delay" value="15"/> >>> >>> >>> >> name="monitor"/> >>> >>> >>> >>> >>> Here, the stonith resource 'ipmilan_node1' has the delay="15". >>> >>> If I run: >>> >>> >>> # pcs stonith update ipmilan_node1 fence_ipmilan ipaddr="10.201.17.1" >>> password="xxx" username="admin"; echo $? >>> 0 >>> >>> >>> I see nothing happen in journald, and the delay argument remains in the >>> 'pcs cluster cib' output. If, however, I do; >>> >>> >>> # /usr/sbin/pcs stonith update ipmilan_node1 fence_ipmilan >>> ipaddr="10.201.17.1" password="xxx" username="admin" delay="0"; echo $? >>> 0 >>> >>> >>> I can see in journald that the CIB was updated and can confirm in 'pcs >>> cluster cib' that the 'delay' value becomes '0'. So it seems that, if an >>> argument previously existed and is NOT specified in an update, it is not >>> removed. >>> >>> Is this intentional for some reason? If so, how would I remove the delay >>> attribute? > > Yes, this is intentional. As far as I remember, update commands in pcs > have always worked this way: > * do not change attributes not specified in the command > * if an attribute is specified with an empty value, remove the attribute > from cluster configuration > * else set specified value of the specified attribute in cluster > configuration > > This means you only need to specify attributes you want to change. You > don't need to bother with attributes you want to keep unchanged. > > If you want to delete the delay attribute, you can do it like this: > pcs stonith update ipmilan_node1 delay= > This will remove delay and keep all the other attributes unchanged. > > I'm not sure why this principle is not documented in pcs man page. We > can fix that, though. > > Note that specifying a stonith agent in the update command does nothing > (which is expected) and is silently ignored by pcs (which is a bug). > > Regards, > Tomas Ah, thank you (and as Andrei)! Is this behaviour not documented in 'pcs stonith help' -> update? Or was I blind and missed it? -- Digimer Papers and Projects: https://alteeve.com/w/ "I am, somehow, less interested in the weight and convolutions of Einstein’s brain than in the near certainty that people of equal talent have lived and died in cotton fields and sweatshops." - Stephen Jay Gould ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] pcs stonith update problems
Dne 16. 07. 21 v 6:35 Andrei Borzenkov napsal(a): On 16.07.2021 01:02, Digimer wrote: Hi all, I've got a predicament... I want to update a stonith resource to remove an argument. Specifically, when resource move nodes, I want to change the stonith delay to favour the new host. This involves adding the 'delay="x"' argument to one stonith resource, and removing it from the other; Example; # pcs cluster cib | grep -B7 -A7 '"delay"' Here, the stonith resource 'ipmilan_node1' has the delay="15". If I run: # pcs stonith update ipmilan_node1 fence_ipmilan ipaddr="10.201.17.1" password="xxx" username="admin"; echo $? 0 I see nothing happen in journald, and the delay argument remains in the 'pcs cluster cib' output. If, however, I do; # /usr/sbin/pcs stonith update ipmilan_node1 fence_ipmilan ipaddr="10.201.17.1" password="xxx" username="admin" delay="0"; echo $? 0 I can see in journald that the CIB was updated and can confirm in 'pcs cluster cib' that the 'delay' value becomes '0'. So it seems that, if an argument previously existed and is NOT specified in an update, it is not removed. Is this intentional for some reason? If so, how would I remove the delay attribute? Yes, this is intentional. As far as I remember, update commands in pcs have always worked this way: * do not change attributes not specified in the command * if an attribute is specified with an empty value, remove the attribute from cluster configuration * else set specified value of the specified attribute in cluster configuration This means you only need to specify attributes you want to change. You don't need to bother with attributes you want to keep unchanged. If you want to delete the delay attribute, you can do it like this: pcs stonith update ipmilan_node1 delay= This will remove delay and keep all the other attributes unchanged. I'm not sure why this principle is not documented in pcs man page. We can fix that, though. Note that specifying a stonith agent in the update command does nothing (which is expected) and is silently ignored by pcs (which is a bug). Regards, Tomas According to similar discussion a couple of days ago, you set attribute to empty value: delay="" ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/ ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
