Re: [ClusterLabs Developers] Proposed future feature: multiple notification scripts

On 04/12/15 12:33 +1100, Andrew Beekhof wrote: >> On 4 Dec 2015, at 2:45 AM, Jan Pokorný <jpoko...@redhat.com> wrote: >> On 02/12/15 17:23 -0600, Ken Gaillot wrote: >>> This will be of interest to cluster front-end developers and anyone who >>> needs event notif

Re: [ClusterLabs Developers] Proposed future feature: multiple notification scripts

On 02/12/15 17:23 -0600, Ken Gaillot wrote: > This will be of interest to cluster front-end developers and anyone who > needs event notifications ... > > One of the new features in Pacemaker 1.1.14 will be built-in > notifications of cluster events, as described by Andrew Beekhof on That >

Re: [ClusterLabs Developers] [ClusterLabs] [Announce] libqb 10.rc4 release

ake srpm"). > There are no actual code changes in this release, most of the patches > are to the build system. Thanks to Jan Pokorný for, er, all of them. > I've bumped the library soname to 0.18.0 which should really have > happened last time. > > Changes from 1.0rc3 > > build: f

Re: [ClusterLabs Developers] [ClusterLabsu] [patch][crmsh] Rework function next_nodeid.

Andrei, On 06/04/16 14:39 +0300, Andrei Maruha wrote: > Attached patch contains a little bit reworked function next_nodeid> > > [...] there are two better aligned channels to propose patches (ordered by preference, at least judging based on

Re: [ClusterLabs Developers] [booth][sbd] GPLv2.1+ clarification request

On 05/04/16 12:33 +0200, Dejan Muhamedagic wrote: > On Wed, Mar 30, 2016 at 05:27:20PM +0200, Jan Pokorný wrote: >> On 24/03/16 17:18 +0100, Jan Pokorný wrote: >>> On 22/03/16 19:18 +0100, Dejan Muhamedagic wrote: >>>> On Mon, Mar 21, 2016 at 10:03:12PM +0100, Jan Po

Re: [ClusterLabs Developers] Resurrecting OCF

On 18/07/16 11:13 -0500, Ken Gaillot wrote: > A suggestion came up recently to formalize a new version of the OCF > resource agent API standard[1]. > > The main goal would be to formalize the API as it is actually used > today, and to replace the "unique" meta-data attribute with two new >

Re: [ClusterLabs Developers] Moving gfs2-utils away from fedorahosted.org

[adding developers list at clusterlabs to CC] On 16/01/17 18:45 +, Andrew Price wrote: > On 19/09/16 17:48, Andrew Price wrote: >> Re: https://communityblog.fedoraproject.org/fedorahosted-sunset-2017-02-28/ >> >> We'll need to find a new host for the cluster projects that haven't >> migrated

[ClusterLabs Developers] Moving cluster project (Was: Moving gfs2-utils away from fedorahosted.org)

On 17/01/17 21:14 +, Andrew Price wrote: > On 17/01/17 19:58, Jan Pokorný wrote: >> So I think we should arrange for a move to pagure.io for this cluster >> project as well if possible, if only to retain the ability to change >> something should there be a need. >

Re: [ClusterLabs Developers] Resurrecting OCF

On 19/08/16 11:14 +0200, Jan Pokorný wrote: > On 19/08/16 10:59 +0200, Jan Pokorný wrote: >> So, having some more thoughts on this, here's the possible action >> plan (just for heartbeat -> clusterlabs transition + deprecating >> some agents, but clusterlabs-staging -> c

Re: [ClusterLabs Developers] Resurrecting OCF

On 19/08/16 13:12 +0200, Jan Pokorný wrote: > On 19/08/16 11:14 +0200, Jan Pokorný wrote: >> On 19/08/16 10:59 +0200, Jan Pokorný wrote: >>> So, having some more thoughts on this, here's the possible action >>> plan (just for heartbeat -> clusterlabs transition

Re: [ClusterLabs Developers] Moving cluster project (Was: Moving gfs2-utils away from fedorahosted.org)

On 17/01/17 22:27 +0100, Jan Pokorný wrote: > On 17/01/17 21:14 +, Andrew Price wrote: >> On 17/01/17 19:58, Jan Pokorný wrote: >>> So I think we should arrange for a move to pagure.io for this cluster >>> project as well if possible, if only to retain the abil

[ClusterLabs Developers] Pagure.io as legacy codebases/distribution files/documentation hosting (Was: Moving cluster project)

On 28/02/17 03:18 +0100, Jan Pokorný wrote: > On 17/01/17 22:27 +0100, Jan Pokorný wrote: >> On 17/01/17 21:14 +, Andrew Price wrote: >>> On 17/01/17 19:58, Jan Pokorný wrote: >>>> So I think we should arrange for a move to pagure.io for this cluster >>>

Re: [ClusterLabs Developers] Potential logo for Cluster Labs

On 25/08/16 09:17 -0500, Ken Gaillot wrote: > On 08/25/2016 09:02 AM, Kristoffer Grönlund wrote: >> Klaus Wenninger writes: >> >>> On 08/25/2016 03:13 PM, Andrew Price wrote: On 25/08/16 13:58, Klaus Wenninger wrote: > On 08/25/2016 12:49 PM, Andrew Price wrote:

Re: [ClusterLabs Developers] Resurrecting OCF

On 18/08/16 15:31 +0200, Kristoffer Grönlund wrote: > A pet peeve of mine would also be to move heartbeat/IPaddr2 to > clusterlabs/IP, to finally get rid of that weird 2 in the name... Just recalled I used to be uncomfortable with "apache" (also present in rgmanager's breed of RAs) as it's no

Re: [ClusterLabs Developers] Resurrecting OCF

metadata op) and/or the exit reason[1]. > Maybe only on successful start operations to minimise the noise? > > [1] Shouldn’t be too hard with some extra fields for 'struct > svc_action_private_s’ or svc_action_t > > >> On 19 Aug 2016, at 6:59 PM, Jan Pokorný <jp

[ClusterLabs Developers] RA as a systemd wrapper -- the right way?

Hello, https://github.com/ClusterLabs/resource-agents/pull/846 seems to be a first crack on integrating systemd to otherwise init-system-unaware resource-agents. As pacemaker already handles native systemd integration, I wonder if it wouldn't be better to just allow, on top of that, perhaps as

Re: [ClusterLabs Developers] Resurrecting OCF

On 15/08/16 12:37 +0200, Jan Pokorný wrote: > On 18/07/16 11:13 -0500, Ken Gaillot wrote: >> A suggestion came up recently to formalize a new version of the OCF >> resource agent API standard[1]. >> >> The main goal would be to formalize the API as it is actually us

Re: [ClusterLabs Developers] Potential logo for Cluster Labs

On 24/08/16 12:50 -0500, Ken Gaillot wrote: > I was doodling the other day and came up with a potential logo for > Cluster Labs. I've attached an example of what I came up with. It's > meant to subtly represent an outer "C" of resources around an inner "L" > of nodes. > > We have a Pacemaker logo

[ClusterLabs Developers] @ClusterLabs/devel COPR with new libqb (Was: [ClusterLabs] libqb 1.0.1 release)

On 24/11/16 10:42 +, Christine Caulfield wrote: > I am very pleased to announce the 1.0.1 release of libqb For instant tryout on Fedora/EL-based distros, there is already a habitual COPR build. But this time around, I'd like to introduce some advancements in the process... * * * First, we

Re: [ClusterLabs Developers] FenceAgentAPI

On 06/03/17 17:12 -0500, Digimer wrote: > The old FenceAgentAPI document on fedorahosted is gone now that fedora > hosted is closed. So I created a copy on the clusterlabs wiki: > > http://wiki.clusterlabs.org/wiki/FenceAgentAPI Note that just few days ago I've announced that the page has

Re: [ClusterLabs Developers] checking all procs on system enough during stop action?

On 24/04/17 17:32 +0200, Jehan-Guillaume de Rorthais wrote: > On Mon, 24 Apr 2017 17:08:15 +0200 > Lars Ellenberg wrote: > >> On Mon, Apr 24, 2017 at 04:34:07PM +0200, Jehan-Guillaume de Rorthais wrote: >>> Hi all, >>> >>> In the PostgreSQL Automatic Failover (PAF)

Re: [ClusterLabs Developers] [libqb] heads-up: logging not working with binutils-2.29 standard linker (ld.bfd)

On 31/07/17 21:55 +0200, Jan Pokorný wrote: > This might be of interest *now* if you are fiddling with bleeding > edge, or *later* when the distros adopt that version of binutils or > newer: Root cause is currently unknown, but the good news is that > the failure will be captured

[ClusterLabs Developers] [libqb] heads-up: logging not working with binutils-2.29 standard linker (ld.bfd)

This might be of interest *now* if you are fiddling with bleeding edge, or *later* when the distros adopt that version of binutils or newer: Root cause is currently unknown, but the good news is that the failure will be captured by the test suite. At least this was the case with the recent mass

[ClusterLabs Developers] [HA/ClusterLabs Summit] Key-Signing Party, 2017 Edition

Hello cluster masters :-) as there's little less than 7 weeks left to "The Summit" meetup (), it's about time to get the ball rolling so we can voluntarily augment the digital trust amongst us the attendees, on OpenGPG basis. Doing that, we'll actually establish a

Re: [ClusterLabs Developers] [ClusterLabs] [HA/ClusterLabs Summit] Key-Signing Party, 2017 Edition

On 23/07/17 12:32 +0100, Adam Spiers wrote: > Jan Pokorný <jpoko...@redhat.com> wrote: >> So, going to attend summit and want your key signed while reciprocally >> spreading the web of trust? >> Awesome, let's reuse the steps from the last time: >> >>

Re: [ClusterLabs Developers] bundle/docker: zombie process on resource stop

On 27/07/17 17:40 -0500, Ken Gaillot wrote: > On Thu, 2017-07-27 at 23:26 +0200, Jan Pokorný wrote: >> On 24/07/17 17:59 +0200, Valentin Vidic wrote: >>> On Mon, Jul 24, 2017 at 09:57:01AM -0500, Ken Gaillot wrote: >>>> Are you sure you have pacemaker 1.1.1

Re: [ClusterLabs Developers] bundle/rkt: port-mapping numbers/names

On 19/07/17 09:49 -0500, Ken Gaillot wrote: > On 07/19/2017 01:20 AM, Valentin Vidic wrote: >> Another issue with the rkt containers is the port-mapping. Each container >> defines exposed ports: >> >> "ports": [ >> { >> "name": "http", >>

Re: [ClusterLabs Developers] bundle/docker: zombie process on resource stop

On 24/07/17 17:59 +0200, Valentin Vidic wrote: > On Mon, Jul 24, 2017 at 09:57:01AM -0500, Ken Gaillot wrote: >> Are you sure you have pacemaker 1.1.17 inside the container as well? The >> pid-1 reaping stuff was added then. > > Yep, the docker container from the bundle example got an older >

Re: [ClusterLabs Developers] ocf_take_lock is NOT actually safe to use

On 21/06/17 16:40 +0200, Lars Ellenberg wrote: > Repost to a wider audience, to raise awareness for this. Appreciated, Lars. Adding developers ML for possibly even larger outreach. > ocf_take_lock may or may not be better than nothing. > > It at least "annotates" that the auther would like to

Re: [ClusterLabs Developers] [ClusterLabs] [HA/ClusterLabs Summit] Key-Signing Party, 2017 Edition

On 24/07/17 16:59 +0200, Jan Pokorný wrote: > On 23/07/17 12:32 +0100, Adam Spiers wrote: >> Jan Pokorný <jpoko...@redhat.com> wrote: >>> So, going to attend summit and want your key signed while reciprocally >>> spreading the web of trust? >>> Awesome

Re: [ClusterLabs Developers] [libqb] heads-up: logging not working with binutils-2.29 standard linker (ld.bfd)

On 03/08/17 20:50 +0200, Valentin Vidic wrote: >> Proper solution: >> - give me few days to investigate better ways to deal with this well, that estimate was off... by far :) But given the goals of - as high level of isolation of the client space from the linker (respectively toolchain)

Re: [ClusterLabs Developers] New LVM resource agent name (currently LVM-activate)

[this follow-up is mostly to re-CC some people that were gradually omitted as the thread progressed, I am not sure who's subscribed and who not with them] On 23/11/17 20:27 +0100, Jan Pokorný wrote: > On 23/11/17 16:54 +0800, Eric Ren wrote: >>> What about VolumeGroup (in t

Re: [ClusterLabs Developers] [libqb] heads-up: logging not working with binutils-2.29 standard linker (ld.bfd)

On 19/10/17 22:49 +0200, Jan Pokorný wrote: > The reconciling patchset is not merged yet, but I'd say it's in the > good shape: https://github.com/ClusterLabs/libqb/pull/266 > > Testing is requested, of course ;) We finally got to merge it with some ulterior changes, and there's jus

Re: [ClusterLabs Developers] RA as a systemd wrapper -- the right way?

On 02/12/17 21:00 +0100, Jan Pokorný wrote: > https://jdebp.eu/FGA/unix-daemon-readiness-protocol-problems.html > > Quoting it: > Of course, only the service program itself can determine exactly > when this point [of being ready, that, "is about to enter its main >

Re: [ClusterLabs Developers] [RFC] Time to migrate authoritative source forge elsewhere?

On 07/06/18 11:10 +, Nils Carlson wrote: > On 2018-06-07 08:58, Kristoffer Grönlund wrote: >> Jan Pokorný writes: >>> AFAIK this doesn't address the qualitative complaint I have. It makes >>> for a very poor experience when there's no readily available w

Re: [ClusterLabs Developers] [RFC] Time to migrate authoritative source forge elsewhere?

On 04/06/18 09:23 +0200, Jan Pokorný wrote: > As a second step, it might also be wise to start offering release > tarballs elsewhere, preferrably OpenPGP-signed proper releases > (as in "make dist" or the like) -- then it can be served practically > from whatever location

Re: [ClusterLabs Developers] [RFC] Time to migrate authoritative source forge elsewhere?

On 07/06/18 15:40 -0500, Ken Gaillot wrote: > On Thu, 2018-06-07 at 11:01 -0400, Digimer wrote: >> I think we need to hang tight and wait to see what the landscape >> looks like after the dust settles. There are a lot of people on >> different projects under the Clusterlabs group. To have them all

Re: [ClusterLabs Developers] [RFC] Time to migrate authoritative source forge elsewhere?

On 07/06/18 08:48 +0200, Kristoffer Grönlund wrote: > Jan Pokorný writes: >> But with the latest headlines on where that site is likely headed, >> I think it's a great opportunity for us to possibly jump on the >> bandwagon inclined more towards free (as in freedom) s

Re: [ClusterLabs Developers] [libqb] heads-up: logging not working with binutils-2.29 standard linker (ld.bfd)

On 19/10/17 22:49 +0200, Jan Pokorný wrote: > On 03/08/17 20:50 +0200, Valentin Vidic wrote: >>> Proper solution: >>> - give me few days to investigate better ways to deal with this > > well, that estimate was off... by far :) > > But given the goals

Re: [ClusterLabs Developers] New challenges with corosync 3/kronosnet + pacemaker

On 09/02/18 17:55 -0600, Ken Gaillot wrote: > On Fri, 2018-02-09 at 18:54 -0500, Digimer wrote: >> On 2018-02-09 06:51 PM, Ken Gaillot wrote: >>> On Fri, 2018-02-09 at 12:52 -0500, Digimer wrote: >>>> On 2018-02-09 03:27 AM, Jan Pokorný wrote: >>>>> the

[ClusterLabs Developers] [ANTICIPATED FAQ] libqb v1.0.3 vs. binutils' linker (Was: [Announce] libqb 1.0.3 release)

I've meant to spread following piece advice but forgot... On 21/12/17 17:45 +0100, Jan Pokorný wrote: > On 21/12/17 14:40 +, Christine Caulfield wrote: >> We are pleased to announce the release of libqb 1.0.3 >> >> >> Source code is available at: >> htt

Re: [ClusterLabs Developers] CIB daemon up and running

Hello Rohit, On 31/07/18 05:03 +, Rohit Saini wrote: > After "pcs cluster start", how would I know if my CIB daemon has > come up and is initialized properly. > Currently I am checking output of "cibadmin -Q" periodically and > when I get the output, I consider CIB daemon has come up and >

Re: [ClusterLabs Developers] CIB daemon up and running

On 13/08/18 10:19 -0500, Ken Gaillot wrote: > On Mon, 2018-08-13 at 05:36 +, Rohit Saini wrote: >> Gentle Reminder!! >>   >> From: Rohit Saini  >> Sent: 31 July 2018 10:34 >> To: 'developers@clusterlabs.org' >> Subject: CIB daemon up and running >>   >> Hello, >>   >> After “pcs cluster

Re: [ClusterLabs Developers] Impact of changing Pacemaker daemon names on other projects?

On 16/04/18 14:32 +0200, Klaus Wenninger wrote: > On 04/16/2018 01:52 PM, Jan Pokorný wrote: >> On 29/03/18 11:13 -0500, Ken Gaillot wrote: >>> 4. Public API symbols: for example, crm_meta_name() -> >>> pcmk_meta_name(). This would be a huge project with huge i

Re: [ClusterLabs Developers] Impact of changing Pacemaker daemon names on other projects?

On 29/03/18 11:13 -0500, Ken Gaillot wrote: > As I'm sure you've seen, there is a strong sentiment on the users list > to change all the Pacemaker daemon names in Pacemaker 2.0.0, mainly to > make it easier to read the logs. > > This will obviously affect any other scripts and projects that look

[ClusterLabs Developers] [questionnaire] Do you overload pacemaker's meta-attributes to track your own data?

Hello, and since it is a month since the preceding attempt to gather some feedback, welcome to yet another simple set of questions that I will be glad to have answered by as many of you as possible, as an auxiliary indicator what's generally acceptable and what's not within the userbase. This

Re: [ClusterLabs Developers] [HA] future of OpenStack OCF resource agents (was: resource-agents v4.2.0)

On 24/10/18 14:42 +0200, Valentin Vidic wrote: > On Wed, Oct 24, 2018 at 01:25:54PM +0100, Adam Spiers wrote: >> No doubt I've missed some pros and cons here. At this point >> personally I'm slightly leaning towards keeping them in the >> openstack-resource-agents - but that's assuming I can

Re: [ClusterLabs Developers] [RFC] Time to migrate authoritative source forge elsewhere?

On 08/06/18 00:21 +0200, Jan Pokorný wrote: > On 07/06/18 15:40 -0500, Ken Gaillot wrote: >> On Thu, 2018-06-07 at 11:01 -0400, Digimer wrote: >>> I think we need to hang tight and wait to see what the landscape >>> looks like after the dust settles. There are a lot

Re: [ClusterLabs Developers] Heads up for potential Pacemaker API change

On 01/11/18 16:41 -0500, Ken Gaillot wrote: > I ran into a situation recently where a fix would require changing > libpe_status's pe_working_set_t data type. > > I ran into a situation recently where a fix would require changing > libpe_status's pe_working_set_t data type. > For most data types

[ClusterLabs Developers] [RFC][pacemaker] Antora as a successor for the current publication platform base on (abandoned?) publican

I am now talking about documents as available, e.g., at: https://clusterlabs.org/pacemaker/doc/ (Versioned documentation) Sadly, I've come to realize that publican is no longer being developed, and while this alone is bearable since it fulfills its role well, worse, some distros are not (going

Re: [ClusterLabs Developers] [RFC][pacemaker] Antora as a successor for the current publication platform base on (abandoned?) publican

> Antora looks interesting. The biggest downside vs publican is that it > appears to be only a static website generator, i.e. it would not > generate PDF, epub, or single-page HTML the way we do now. Couple of good questions was, coincidentally, raised "yesterday":

Re: [ClusterLabs Developers] [RFC][pacemaker] Antora as a successor for the current publication platform base on (abandoned?) publican

On 17/01/19 21:00 +0100, Jan Pokorný wrote: > For instance, also Fedora project, ironically with the intimately > strongest inclination towards this project, decided to ditch it in > favour of Antora: > > https://fedoramagazine.org/fedora-docs-overhaul/ [...] > My ask is

Re: [ClusterLabs Developers] libqb: Re: 633f262 logging: Remove linker 'magic' and just use statics for logging callsites (#322)

Late to the party (for some rather personal reasons), but anyway, I don't see any progress while there's a pressing need to resolve at least a single thing for sure before the release, so here I go... On 18/01/19 18:53 +0100, Lars Ellenberg wrote: > On Thu, Jan 17, 2019 at 09:09:11AM +1100,

[ClusterLabs Developers] Easy opt-in copyright delegation assignment (Was: Feedback wanted: proposed new copyright policy for Pacemaker)

On 11/03/19 13:49 -0500, Ken Gaillot wrote: > There's a pull request for the new policy in case anyone is interested: > > https://github.com/ClusterLabs/pacemaker/pull/1716 As I mentioned there, rhis could be a possible next evolution step, but it's in no hurry (unlike the former one of reality

Re: [ClusterLabs Developers] Karma needed - Re: Updated kronosnet Fedora / EPEL packages to v1.8

Hello Digimer, On 11/04/19 01:09 -0400, digimer wrote: > Would anyone with time and inclination please review / vote for > these packages? Would like to get them pushed out if possible, short > a vote each. FYI, you will be allowed to push to stable in 7 days at latest since filing the update

Re: [ClusterLabs Developers] FYI: github policy change potentially affecting ssh/app access to repositories

On 14/04/19 22:48 +0200, Valentin Vidic wrote: > On Wed, Apr 10, 2019 at 05:44:45PM -0500, Ken Gaillot wrote: >> Florian Haas and Kristoffer Grönlund noticed that the ClusterLabs >> organization on github currently carries over any app access that >> members have given to their own accounts. > >

[ClusterLabs Developers] If anybody develops against libpe_status.so: skipped soname bump (Was: Pacemaker 2.0.2 final release now available)

> On Thu, 2019-06-06 at 10:12 -0500, Ken Gaillot wrote: > > Source code for the Pacemaker 2.0.2 and 1.1.21 releases is now > available: > > https://github.com/ClusterLabs/pacemaker/releases/tag/Pacemaker-2.0.2 > > https://github.com/ClusterLabs/pacemaker/releases/tag/Pacemaker-1.1.21 In

Re: [ClusterLabs Developers] If anybody develops against libpe_status.so: skipped soname bump (Was: Pacemaker 2.0.2 final release now available)

On 14/06/19 20:13 +0200, Jan Pokorný wrote: > For the piece of mind, I am detailing the respective library that > would likely have been eligible for an explicit soname bump and why. > If you feel affected, please speak up so we have a clear incentive to > publish a "hotfix

Re: [ClusterLabs Developers] If anybody develops against libpe_status.so: skipped soname bump (Was: Pacemaker 2.0.2 final release now available)

On 14/06/19 14:56 -0500, Ken Gaillot wrote: > On Fri, 2019-06-14 at 20:13 +0200, Jan Pokorný wrote: >>> On Thu, 2019-06-06 at 10:12 -0500, Ken Gaillot wrote: >>> >>> Source code for the Pacemaker 2.0.2 and 1.1.21 releases is now >>> available: >>>

Re: [ClusterLabs Developers] If anybody develops against libpe_status.so: skipped soname bump (in 2.0.2)

On 14/06/19 18:46 -0500, Ken Gaillot wrote: > On Fri, 2019-06-14 at 23:57 +0200, Jan Pokorný wrote: >> On 14/06/19 14:56 -0500, Ken Gaillot wrote: >>> On Fri, 2019-06-14 at 20:13 +0200, Jan Pokorný wrote: >>>>> On Thu, 2019-06-06 at 10:12 -0500, Ken Gaillot

[ClusterLabs Developers] Multiple processes appending to the same log file questions (Was: Pacemaker detail log directory permissions)

[let's move this to developers@cl.o, please drop users on response unless you are only subscribed there, I tend to only respond to the lists] On 30/04/19 13:55 +0200, Jan Pokorný wrote: > On 30/04/19 07:55 +0200, Ulrich Windl wrote: >>>>> Jan Pokorný schrieb am 2

Re: [ClusterLabs Developers] Using ClusterLabs logo

On 29/04/19 16:31 +0200, Kristoffer Grönlund wrote: > Tomas Jelinek writes: >> Is it OK to use ClusterLabs logo as a favicon for pcs in upstream? If >> so, are there any conditions to meet? > > Yes, this would be OK to me at least (as the creator of the logo)! > >> >> I went through new logo

Re: [ClusterLabs Developers] FYI: github policy change potentially affecting ssh/app access to repositories

On 25/04/19 22:41 +0200, Jan Pokorný wrote: > On 25/04/19 11:27 -0500, Ken Gaillot wrote: >> FYI OAuth access restrictions are now in place on the ClusterLabs >> organization account. >> >> [...] >> >> If you use an app that needs repo access, I believ

[ClusterLabs Developers] Reminder that /proc is just rather an unreliable quirk, not a firm grip on processes

[in a sense, this is a follow-up for my recent post: https://lists.clusterlabs.org/pipermail/users/2019-May/025749.html] Have come across an interesting experience regarding /proc traversal: https://rkeene.org/projects/info/wiki/173 (as well as a danger of exhausting available inodes mentioned

Re: [ClusterLabs Developers] Reminder that /proc is just rather an unreliable quirk, not a firm grip on processes

On 03/07/19 11:45 +0200, Jan Pokorný wrote: > [...] Accidentally, something fundamentally related to process scan and related imprecize overapproximation just popped up: https://lists.clusterlabs.org/pipermail/users/2019-July/025978.html -- Jan (Poki) pgpyJOvTXCBYc.pgp Description:

Re: [ClusterLabs Developers] [ClusterLabs] Coming in 2.0.2: check whether a date-based rule is expired

On 16/04/19 12:38 -0500, Ken Gaillot wrote: > We are adding a "crm_rule" command Wouldn't `pcmk-rule` be a more sensible command name -- I mean, why not to benefit from not suffering the historical burden in this case, given that `crm` in the broadest "almost anything that can be associated with

Re: [ClusterLabs Developers] performance problems with ocf resource nfsserver script

Hello Eberhard, On 11/09/19 10:01 +0200, Eberhard Kuemmerle wrote: > I use pacemaker with a some years old hardware. > In combination with an rsync backup, I had nfsserver monitoring > timeouts that resulted in stonith fencing events... > > So I tested the ocf resource nfsserver script and

Re: [ClusterLabs Developers] Extend enumeration of OCF return values

On 16/10/19 09:18 +, Yan Gao wrote: > On 10/15/19 4:31 PM, Ken Gaillot wrote: >> On Tue, 2019-10-15 at 13:08 +0200, Tony den Haan wrote: >>> Hi, >>> I ran into getting "error 1" from portblock, so OCF_ERR_GENERIC, >>> which for me doesn't guarantee the error was RC from portblock or >>>

Re: [ClusterLabs Developers] kronosnet v1.12 released

On 20/09/19 05:22 +0200, Fabio M. Di Nitto wrote: > We are pleased to announce the general availability of kronosnet v1.12 > (bug fix release) > > [...] > > * Add support for musl libc Congrats, and the above is a great news, since I've been toying with an idea of putting together a truly

[ClusterLabs Developers] FYI: looks like there are DNS glitches with clusterlabs.org subdomains

Neither bugs.c.o nor lists.c.o work for me ATM. Either it resolves by itself, or Ken will intervene, I believe. -- Jan (Poki) pgpVtzxiRrw_d.pgp Description: PGP signature ___ Manage your subscription:

Re: [ClusterLabs Developers] [deveoplers] maintenance vs is-managed; different levels of the maintenance property

On 28/11/19 11:36 +, Yan Gao wrote: > On 11/28/19 1:19 AM, Ken Gaillot wrote: >> There is some room for coming up with better option naming and >> meaning. For example maybe the cluster-wide "maintenance-mode" >> should be something like "force-maintenance" to make clear it takes >>

[ClusterLabs Developers] Consensus on to-avoid in pacemaker, unnecessary proliferation of redundant goal-achievers, undocumented options and such? (Was: maintenance vs is-managed; different levels of

On 18/12/19 02:36 +0100, Jan Pokorný wrote: > [...] > > - based on the above, increase of redundance/burden, plus > maintenance costs not just at pacemaker itself (more complex > codebase) but also any external tooling incl. higher level tools > (ditto, plus ensuring th

[ClusterLabs Developers] No ruinings in 2020! (Was: I will ruin your Christmas holidays Developers!)

On 21/12/19 01:29 -0500, Digimer wrote: > I'm not sure how this got through the queue... Sorry for the noise. in fact, it did not from what I can see, meaning that you (and perhaps other shadow moderators) do a stellar job, despite this not happening in a direct sight -- or in other words,

Re: [ClusterLabs Developers] No ruinings in 2020! (Was: I will ruin your Christmas holidays Developers!)

On 02/01/20 12:47 +0100, Jan Pokorný wrote: > On 21/12/19 01:29 -0500, Digimer wrote: >> I'm not sure how this got through the queue... Sorry for the noise. > > in fact, it did not from what I can see, meaning that you (and perhaps > other shadow moderators) do a st