Re: [ClusterLabs] Antw: [EXT] Preventing a resource from migrating to / starting on a node
The use case here is for external code (DRBD) to ban a resource from a node. While DRBD could add/remove location constraints, it's better to have permanent (rule-based) location constraints in the configuration, and let DRBD just set or unset a node attribute to trigger the constraint. As a general rule, it's best to avoid automated configuration changes (via resource agents, crons, DRBD, etc.) other than node attributes. There's just more room for something to go wrong. On Tue, 2022-11-29 at 10:50 -0800, Reid Wahl wrote: > On Tue, Nov 29, 2022 at 7:20 AM Madison Kelly > wrote: > > I was taking Ken's advice. Originally my plan was to use location > > constraints, but I assume Ken's reasoning was sound for the node > > attribute approach. > > Location constraints should work for the simple test case you > presented. There's probably some additional nuance that came up in > your discussion with Ken. Rules and node attributes can be more > flexible when the situation is more complex than just "don't run on > the node with this particular node name". > > > On 2022-11-29 02:51, Ulrich Windl wrote: > > > > Why can't you use a plain location constraint? > > > > Madison Kelly schrieb am 29.11.2022 um 05:21 > > in Nachricht > > > > > > -- > > Madison Kelly > > Alteeve's Niche! > > Chief Technical Officer > > c: +1-647-471-0951 > > https://alteeve.com/ > > > > ___ > > Manage your subscription: > > https://lists.clusterlabs.org/mailman/listinfo/users > > > > ClusterLabs home: https://www.clusterlabs.org/ > > -- Ken Gaillot ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Preventing a resource from migrating to / starting on a node
On Tue, Nov 29, 2022 at 7:34 AM Madison Kelly wrote: > > On 2022-11-29 00:31, Reid Wahl wrote: > > On Mon, Nov 28, 2022 at 8:21 PM Madison Kelly wrote: > > This question builds on questions I was talking to kgaillot on IRC. > > I am try to prevent a resource from being allowed to migrate to or start on a > given node. When I asked about this, Ken talked about node attributes, which > I've been trying to implement. > > To try to figure this out / test this, I setup an attribute against a > resource called 'srv01-sql' called 'drbd-fenced_srv01-psql' that sets a > location constraint of -INFINITY. I had the resource running on 'mk-a01n01' > and then set 'drbd-fenced_srv01-psql=1' to trigger the constraint against > 'mk-a01n02'. I verified this was set, then tried migrating it, and it happily > migrated. > > Clearly I am missing something. :) > > > [root@mk-a01n01 ~]# crm_attribute --type nodes --node mk-a01n02 --name > drbd-fenced_srv01-sql --query > scope=nodes name=drbd-fenced_srv01-sql value=1 > > [root@mk-a01n01 ~]# pcs constraint location config > Location Constraints: > Resource: srv01-sql > Enabled on: > Node: mk-a01n02 (score:100) > Node: mk-a01n01 (score:200) > Constraint: location-srv01-sql > Rule: score=-INFINITY > Expression: drbd-fenced_srv01-sql eq 0 > Resource: srv02-web > Enabled on: > Node: mk-a01n02 (score:100) > Node: mk-a01n01 (score:200) > > [root@mk-a01n01 ~]# crm_attribute --type nodes --node mk-a01n02 --name > drbd-fenced_srv01-sql --query > scope=nodes name=drbd-fenced_srv01-sql value=1 > > [root@mk-a01n01 ~]# pcs resource status srv01-sql > * srv01-sql(ocf::alteeve:server): Started mk-a01n01 > > [root@mk-a01n01 ~]# pcs constraint location srv01-sql prefers mk-a01n02=200 > mk-a01n01=100 > > [root@mk-a01n01 ~]# pcs resource status srv01-sql > * srv01-sql(ocf::alteeve:server): Migrating mk-a01n01 > > [root@mk-a01n01 ~]# pcs resource status srv01-sql > * srv01-sql(ocf::alteeve:server): Started mk-a01n02 > > > I feel like this shouldn't be so complicated, so I am likely over-thinking > this, or missing something obvious... > > -- > Madison Kelly > Alteeve's Niche! > Chief Technical Officer > c: +1-647-471-0951 > https://alteeve.com/ > > The configured rule prevents srv01-sql from running on a node where > the drbd-fenced_srv01-sql attribute is set to 0. It looks like it's > set to 1. > > Maybe I'm misunderstanding though -- if I am, can you help clarify and > send the CIB so that I can mess around with it? > > Excuse me one second... > > "AARG!!" > > OK, now I am better. Thank you, that was the problem. :) Haha, happy to help. That type of thing happens to me a couple times a week. > > -- > Madison Kelly > Alteeve's Niche! > Chief Technical Officer > c: +1-647-471-0951 > https://alteeve.com/ -- Regards, Reid Wahl (He/Him) Senior Software Engineer, Red Hat RHEL High Availability - Pacemaker ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Antw: [EXT] Preventing a resource from migrating to / starting on a node
On Tue, Nov 29, 2022 at 7:20 AM Madison Kelly wrote: > > I was taking Ken's advice. Originally my plan was to use location > constraints, but I assume Ken's reasoning was sound for the node attribute > approach. Location constraints should work for the simple test case you presented. There's probably some additional nuance that came up in your discussion with Ken. Rules and node attributes can be more flexible when the situation is more complex than just "don't run on the node with this particular node name". > > On 2022-11-29 02:51, Ulrich Windl wrote: > > Why can't you use a plain location constraint? > > Madison Kelly schrieb am 29.11.2022 um 05:21 in Nachricht > > > -- > Madison Kelly > Alteeve's Niche! > Chief Technical Officer > c: +1-647-471-0951 > https://alteeve.com/ > > ___ > Manage your subscription: > https://lists.clusterlabs.org/mailman/listinfo/users > > ClusterLabs home: https://www.clusterlabs.org/ -- Regards, Reid Wahl (He/Him) Senior Software Engineer, Red Hat RHEL High Availability - Pacemaker ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Preventing a resource from migrating to / starting on a node
On 2022-11-29 00:31, Reid Wahl wrote: On Mon, Nov 28, 2022 at 8:21 PM Madison Kelly wrote: This question builds on questions I was talking to kgaillot on IRC. I am try to prevent a resource from being allowed to migrate to or start on a given node. When I asked about this, Ken talked about node attributes, which I've been trying to implement. To try to figure this out / test this, I setup an attribute against a resource called 'srv01-sql' called 'drbd-fenced_srv01-psql' that sets a location constraint of -INFINITY. I had the resource running on 'mk-a01n01' and then set 'drbd-fenced_srv01-psql=1' to trigger the constraint against 'mk-a01n02'. I verified this was set, then tried migrating it, and it happily migrated. Clearly I am missing something. :) [root@mk-a01n01 ~]# crm_attribute --type nodes --node mk-a01n02 --name drbd-fenced_srv01-sql --query scope=nodes name=drbd-fenced_srv01-sql value=1 [root@mk-a01n01 ~]# pcs constraint location config Location Constraints: Resource: srv01-sql Enabled on: Node: mk-a01n02 (score:100) Node: mk-a01n01 (score:200) Constraint: location-srv01-sql Rule: score=-INFINITY _expression_: drbd-fenced_srv01-sql eq 0 Resource: srv02-web Enabled on: Node: mk-a01n02 (score:100) Node: mk-a01n01 (score:200) [root@mk-a01n01 ~]# crm_attribute --type nodes --node mk-a01n02 --name drbd-fenced_srv01-sql --query scope=nodes name=drbd-fenced_srv01-sql value=1 [root@mk-a01n01 ~]# pcs resource status srv01-sql * srv01-sql(ocf::alteeve:server): Started mk-a01n01 [root@mk-a01n01 ~]# pcs constraint location srv01-sql prefers mk-a01n02=200 mk-a01n01=100 [root@mk-a01n01 ~]# pcs resource status srv01-sql * srv01-sql(ocf::alteeve:server): Migrating mk-a01n01 [root@mk-a01n01 ~]# pcs resource status srv01-sql * srv01-sql(ocf::alteeve:server): Started mk-a01n02 I feel like this shouldn't be so complicated, so I am likely over-thinking this, or missing something obvious... -- Madison Kelly Alteeve's Niche! Chief Technical Officer c: +1-647-471-0951 https://alteeve.com/ The configured rule prevents srv01-sql from running on a node where the drbd-fenced_srv01-sql attribute is set to 0. It looks like it's set to 1. Maybe I'm misunderstanding though -- if I am, can you help clarify and send the CIB so that I can mess around with it? Excuse me one second... "AARG!!" OK, now I am better. Thank you, that was the problem. :) -- Madison Kelly Alteeve's Niche! Chief Technical Officer c: +1-647-471-0951 https://alteeve.com/ ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Antw: [EXT] Preventing a resource from migrating to / starting on a node
I was taking Ken's advice. Originally my plan was to use location constraints, but I assume Ken's reasoning was sound for the node attribute approach. On 2022-11-29 02:51, Ulrich Windl wrote: Why can't you use a plain location constraint? Madison Kelly schrieb am 29.11.2022 um 05:21 in Nachricht -- Madison Kelly Alteeve's Niche! Chief Technical Officer c: +1-647-471-0951 https://alteeve.com/ ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
[ClusterLabs] pcs 0.11.4 released
I am happy to announce the latest release of pcs, version 0.11.4. Source code is available at: https://github.com/ClusterLabs/pcs/archive/v0.11.4.tar.gz or https://github.com/ClusterLabs/pcs/archive/v0.11.4.zip This release brings improved validation of resource instance attributes and cluster properties. There are also important fixes for a security issue and few regressions. Complete change log for this release: ## [0.11.4] - 2022-11-21 ### Security - CVE-2022-2735 pcs: obtaining an authentication token for hacluster user could lead to privilege escalation ([rhbz#2116841]) ### Added - API v2 providing asynchronous interface for pcsd. Note that this feature is in tech-preview state and thus may be changed in the future - Support for resource/stonith agent self-validation of instance attributes via pacemaker ([rhbz#2112270]) - Support for booth 'enable-authfile' fix ([rhbz#2116295]) ### Fixed - `pcs resource manage --monitor` no longer enables monitor operation for all resources in a group if only one of the resources was requested to become managed ([rhbz#2092950]) - `pcs resource restart` command works again (broken in pcs-0.11.3) ([rhbz#2102663]) - Misleading error message from `pcs booth sync` when booth config directory (`/etc/booth`) is missing ([rhbz#1791670]) - Creating a promotable or globally-unique clones is not allowed for non-ocf resource agents ([rhbz#1493416]) - Improved cluster properties validators, OCF 1.1 now supported ([rhbz#2019464]) - `pcs property set/unset` forbid manipulation of specific cluster properties ([rhbz#1620043]) Thanks / congratulations to everyone who contributed to this release, including Fabio M. Di Nitto, Ivan Devat, lixin, Lucas Kanashiro, Michal Pospisil, Miroslav Lisik, Ondrej Mular and Tomas Jelinek. Cheers, Tomas [rhbz#1493416]: https://bugzilla.redhat.com/show_bug.cgi?id=1493416 [rhbz#1620043]: https://bugzilla.redhat.com/show_bug.cgi?id=1620043 [rhbz#1791670]: https://bugzilla.redhat.com/show_bug.cgi?id=1791670 [rhbz#2019464]: https://bugzilla.redhat.com/show_bug.cgi?id=2019464 [rhbz#2092950]: https://bugzilla.redhat.com/show_bug.cgi?id=2092950 [rhbz#2102663]: https://bugzilla.redhat.com/show_bug.cgi?id=2102663 [rhbz#2112270]: https://bugzilla.redhat.com/show_bug.cgi?id=2112270 [rhbz#2116295]: https://bugzilla.redhat.com/show_bug.cgi?id=2116295 [rhbz#2116841]: https://bugzilla.redhat.com/show_bug.cgi?id=2116841 ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
[ClusterLabs] pcs 0.10.15 released
I am happy to announce the latest release of pcs, version 0.10.15. Source code is available at: https://github.com/ClusterLabs/pcs/archive/v0.10.15.tar.gz or https://github.com/ClusterLabs/pcs/archive/v0.10.15.zip This release brings improved validation of resource instance attributes and cluster properties. There are also important fixes for a security issue and few regressions. Complete change log for this release: ## [0.10.15] - 2022-11-23 ### Security - CVE-2022-2735 pcs: obtaining an authentication token for hacluster user could lead to privilege escalation ([rhbz#2116838]) ### Added - Support for resource/stonith agent self-validation of instance attributes via pacemaker ([rhbz#1816852]) - Support for booth 'enable-authfile' fix ([rhbz#2132582]) ### Fixed - `pcs resource manage --monitor` no longer enables monitor operation for all resources in a group if only one of the resources was requested to become managed ([rhbz#1918527]) - Misleading error message from `pcs booth sync` when booth config directory (`/etc/booth`) is missing ([rhbz#1791670]) - `pcs quorum device remove` works again (broken since 0.10.13) ([rhbz#2115326]) - SBD enable from webui works again ([rhbz#2117650]) - Improved cluster properties validators, OCF 1.1 now supported ([rhbz#2112002]) - `pcs property set/unset` forbid manipulation of specific cluster properties ([rhbz#2112263]) Thanks / congratulations to everyone who contributed to this release, including Ivan Devat, lixin, Michal Pospisil, Miroslav Lisik, Ondrej Mular and Tomas Jelinek. Cheers, Tomas [rhbz#1791670]: https://bugzilla.redhat.com/show_bug.cgi?id=1791670 [rhbz#1816852]: https://bugzilla.redhat.com/show_bug.cgi?id=1816852 [rhbz#1918527]: https://bugzilla.redhat.com/show_bug.cgi?id=1918527 [rhbz#2112002]: https://bugzilla.redhat.com/show_bug.cgi?id=2112002 [rhbz#2112263]: https://bugzilla.redhat.com/show_bug.cgi?id=2112263 [rhbz#2115326]: https://bugzilla.redhat.com/show_bug.cgi?id=2115326 [rhbz#2116838]: https://bugzilla.redhat.com/show_bug.cgi?id=2116838 [rhbz#2117650]: https://bugzilla.redhat.com/show_bug.cgi?id=2117650 [rhbz#2132582]: https://bugzilla.redhat.com/show_bug.cgi?id=2132582 ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
