Re: [ClusterLabs] Coming in Pacemaker 2.0.4: crm_mon --include/--exclude

Ken Gaillot writes: > The crm_mon tool for showing cluster status will have --include and -- > exclude options to pick and choose which types of information you want > it to display. Cool! Let me add a related idea: what about providing a way to filter the list of displayed resources? To be mo

Re: [ClusterLabs] Pacemaker trades restart for migration on resource parameter change

"Ulrich Windl" writes: > schrieb am 13.03.2020 um 08:36 in Nachricht > <19666_1584085000_5e6b3808_19666_1044_1_87imj8vh90@lant.ki.iif.hu>: > >> A user noticed that after changing a non‑reloadable (unique) parameter >> of resource A in our cluster, A wasn't restarted as expected. On closer

[ClusterLabs] Pacemaker trades restart for migration on resource parameter change

Hi, A user noticed that after changing a non-reloadable (unique) parameter of resource A in our cluster, A wasn't restarted as expected. On closer inspection it turned out that the parameter change was coupled with a utilization change as well, which necessitated shuffling resources around. All

[ClusterLabs] Finding attributes of a past resource agent invocation

Hi, I suffered unexpected fencing under Pacemaker 2.0.1. I set a resource to unmanaged (crm_resource -r vm-invtest -m -p is-managed -v false), then played with ocf-tester, which left the resource stopped. Finally I deleted the resource (crm_resource -r vm-invtest --delete -t primitive), which le

Re: [ClusterLabs] Antw: [EXT] Coming in Pacemaker 2.0.4: shutdown locks

Ken Gaillot writes: > I think a per-resource option would have more potential to be > confusing than helpful. But, it should be relatively simple to extend > this as a per-resource option, with the global option as a > backward-compatible default, if the demand arises. And then you could immedia

Re: [ClusterLabs] corosync 3.0.1 on Debian/Buster reports some MTU errors

Jean-Francois Malouin writes: > * christine caulfield [20191121 03:19]: > >> On 18/11/2019 21:31, Jean-Francois Malouin wrote: >> >>> However the system log on the nodes reports those much more frequently, a >>> few >>> times a day: >>> >>> Nov 17 23:26:20 node1 corosync[2258]: [KNET ] link

[ClusterLabs] fence agent configuration (was: fencing on iscsi device not working)

Ken Gaillot writes: > I edited it so that the default and description are combined: > > How to determine which machines are controlled by the device. Allowed > values: > > * +static-list:+ check the +pcmk_host_list+ or +pcmk_host_map+ > attribute (this is the default if either one of those is set

Re: [ClusterLabs] fencing on iscsi device not working

Roger Zhou writes: > On 11/3/19 12:56 AM, wf...@niif.hu wrote: > >> Andrei Borzenkov writes: >> >>> According to documentation, pcmk_host_list is used only if >>> pcmk_host_check=static-list which is not default, by default pacemaker >>> queries agent for nodes it can fence and fence_scsi does

Re: [ClusterLabs] fencing on iscsi device not working

Andrei Borzenkov writes: > According to documentation, pcmk_host_list is used only if > pcmk_host_check=static-list which is not default, by default pacemaker > queries agent for nodes it can fence and fence_scsi does not return > anything. The documentation is somewhat vague here. The note abo

Re: [ClusterLabs] Corosync main process was not scheduled for 2889.8477 ms (threshold is 800.0000 ms), though it runs with realtime priority and there was not much load on the node

Jeevan Patnaik writes: > writes: > >> Jeevan Patnaik writes: >> >>> [16187] node1 corosyncwarning [MAIN ] Corosync main process was not >>> scheduled for 2889.8477 ms (threshold is 800. ms). Consider token >>> timeout increase. >>> [...] >>> 2. How to fix this? We have not much load on the

Re: [ClusterLabs] Corosync main process was not scheduled for 2889.8477 ms (threshold is 800.0000 ms), though it runs with realtime priority and there was not much load on the node

Andrei Borzenkov writes: > 04.09.2019 0:27, wf...@niif.hu пишет: > >> Jeevan Patnaik writes: >> >>> [16187] node1 corosyncwarning [MAIN ] Corosync main process was not >>> scheduled for 2889.8477 ms (threshold is 800. ms). Consider token >>> timeout increase. >>> [...] >>> 2. How to fix th

Re: [ClusterLabs] Corosync main process was not scheduled for 2889.8477 ms (threshold is 800.0000 ms), though it runs with realtime priority and there was not much load on the node

Jeevan Patnaik writes: > [16187] node1 corosyncwarning [MAIN ] Corosync main process was not > scheduled for 2889.8477 ms (threshold is 800. ms). Consider token > timeout increase. > [...] > 2. How to fix this? We have not much load on the nodes, the corosync is > already running with RT pri

Re: [ClusterLabs] resource location preference vs utilization

"Ulrich Windl" writes: > schrieb am 15.07.2019 um 18:41 in Nachricht > <87o91vp7vv@lant.ki.iif.hu>: > >> In a mostly symmetrical cluster I've got a couple of resources which >> should only ever run on a subset of the nodes if possible. However, >> utilization constraints seem to prevent o

[ClusterLabs] resource location preference vs utilization

Hi, In a mostly symmetrical cluster I've got a couple of resources which should only ever run on a subset of the nodes if possible. However, utilization constraints seem to prevent optimal resource allocation in some cases: Pacemaker does not migrate other resources to make room for the picky res

Re: [ClusterLabs] Corosync crash

Klecho writes: > During the weekend my corosync daemon suddenly died without anything > in the logs, except this: > > May  5 20:39:16 ZZZ kernel: [1605277.136049] traps: corosync[2811] > trap invalid opcode ip:5635c376f2eb sp:7ffc3e109950 error:0 in > corosync[5635c3745000+47000] > > The version

[ClusterLabs] Pacemaker detail log directory permissions

Hi, Make install creates /var/log/pacemaker with mode 0770, owned by hacluster:haclient. However, if I create the directory as root:root instead, pacemaker.log appears as hacluster:haclient all the same. What breaks in this setup besides log rotation (which can be fixed by removing the su direct

Re: [ClusterLabs] Creating new resource types

"Full Name" writes: > I haven't found any guidelines on how to add new resources. Have you seen http://www.linux-ha.org/doc/dev-guides/ra-dev-guide.html? -- Regards, Feri ___ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mai

Re: [ClusterLabs] Pacemaker 2.0.1-rc4 now available

Ken Gaillot writes: > On Mon, 2019-02-25 at 12:48 +0100, wf...@niif.hu wrote: > >> Ken Gaillot writes: >> >>> We should be getting close to final release. >> >> How close are we to the final release? I'm asking because the Debian >> full freeze date is 2019-03-12 and migration requires 10 day

Re: [ClusterLabs] Pacemaker 2.0.1-rc4 now available

Ken Gaillot writes: > We should be getting close to final release. Hi Ken, How close are we to the final release? I'm asking because the Debian full freeze date is 2019-03-12 and migration requires 10 days now, thus I'd have to upload any significant changes ASAP to catch Debian buster. -- Th

[ClusterLabs] Pacemaker API structure and pkg-config files

Hi, Recently I spent some time mapping the interrelations of the C header files constituting the Pacemaker API. In the end I decided they were so tightly interdependent that there was really no useful way to ship parts of the API separately, thus I did away with the separate lib*-dev Debian packa

Re: [ClusterLabs] Status of Pacemaker 2 support in SBD?

Klaus Wenninger writes: > On 01/11/2019 01:57 AM, wf...@niif.hu wrote: > >> What's the status of Pacemaker 2 support in SBD? I can see several >> commits since the 1.3.1 tag concerning this, but no conclusion. Is the >> current state considered stable enough for packaging? If it is, can we >>

[ClusterLabs] Status of Pacemaker 2 support in SBD?

Hi, What's the status of Pacemaker 2 support in SBD? I can see several commits since the 1.3.1 tag concerning this, but no conclusion. Is the current state considered stable enough for packaging? If it is, can we ask for an official (pre)release (I mean a tag) to work with? -- Thanks, Feri ___

Re: [ClusterLabs] Plea for a new DLM release and thoughts on its Pacemaker interface

David Teigland writes: > On Tue, Jan 08, 2019 at 11:56:18AM +0100, wf...@niif.hu wrote: > >> The DLM git repo accumulated a couple of patches over the 4.0.7 tag, >> would you mind cutting a new release for packaging? > > ok Hi David, I found the ce1e4cc9 commit bumping the version, but neither

[ClusterLabs] Plea for a new DLM release and thoughts on its Pacemaker interface

Hi David, The DLM git repo accumulated a couple of patches over the 4.0.7 tag, would you mind cutting a new release for packaging? Tangentially, would you be interested in an Autotoolized build system? The flag handling repeatedly gives me headaches, and I'd consider contributing that if you aren