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

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

[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

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

[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

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

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

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

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

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

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

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

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. --

[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

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

[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