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 stella

[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, practic

[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 the c

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

Re: [ClusterLabs Developers] Building clufter on EL8

Hi Digimer o/ On 30/10/19 16:24 -0400, Digimer wrote: > While waiting to see what CentOS 8 will do with regard to HA, you are not the only surprised here > I decided to rebuild the rhel 8 packages for our own repo[1]. To > this end, I've rebuilt all packages, except clufter. > > The clufter p

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

[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: https://lists.clusterlabs.org/mailman/listinfo/dev

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 minima

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 found,

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:

[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 i

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 wro

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 (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&quo

[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 retrosp

[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 29.04

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 t

[ClusterLabs Developers] [pacemaker] downstream packagers&direct consumers: is bison prereq OK with you?

It seems extraneous to carry results of *.y files processing the tree (and hence in what we call distribution tarballs at the time). Hence the simple question, are you OK with bison (not yacc, even though the compatibility fix appears to be a sed oneliner) becoming a new dependency? It's also not

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

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

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 believe a request to allow > it will be sent automatically, but if problems arise just mention them > h

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 o

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

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 reg

Re: [ClusterLabs Developers] strange migration-threshold overflow, and fail-count update aborting it's own recovery transition

On 05/04/19 17:19 +0200, Lars Ellenberg wrote: > On Fri, Apr 05, 2019 at 09:56:51AM -0500, Ken Gaillot wrote: >> On Fri, 2019-04-05 at 09:44 -0500, Ken Gaillot wrote: >>> On Fri, 2019-04-05 at 15:50 +0200, Lars Ellenberg wrote: But in this case, someone tried to be smart and set a migrati

[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 r

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, Andrew

Re: [ClusterLabs Developers] [pacemaker] Discretion with glib v2.59.0+ recommended

On 20/01/19 12:44 +0100, Jan Pokorný wrote: > On 18/01/19 20:32 +0100, Jan Pokorný wrote: >> It was discovered that this release of glib project changed sligthly >> some parameters of how distribution of values within hash tables >> structures work, undermining pacemaker&#x

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] [pacemaker] Discretion with glib v2.59.0+ recommended

On 18/01/19 20:32 +0100, Jan Pokorný wrote: > It was discovered that this release of glib project changed sligthly > some parameters of how distribution of values within hash tables > structures work, undermining pacemaker's hard (alas unfeasible) attempt > to turn this dat

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": https://gitlab.com/antora/antora

[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 to

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 in

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

On 01/11/18 17:07 -0500, Ken Gaillot wrote: > FYI there is further discussion happening on the PR: > > https://github.com/ClusterLabs/resource-agents/pull/1147 > > I think we have multiple issues we're trying to solve: > > 1. Discoverability in terms of users knowing what agents may be > availab

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 eithe

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] pacemakerd: error: sysrq_init: Cannot write to /proc/sys/kernel/sysrq: Permission denied (13)

On 19/09/18 14:47 +0800, zhongbin wrote: > More detail: > my operating system is Debian 8 (jessie) . > > At 2018-09-19 14:00:42, "钟彬" wrote: > > When I use a non - root user to start pacemaker-2.0.0, Running pacemaker as non-root is not a good choice, I am afraid. It simply wasn't d

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 start”

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

[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 time

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 avai

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

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 freed

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

Good Monday morning, almost half a year ago, when I was writing the lines below in a response to a tangential topic, I wouldn't have believed we are going to be so close towards reconsidering the stay on GitHub (GH), said proprietaty service [1]: On 09/01/18 15:37 +, Adam Spiers wrote:

[ClusterLabs Developers] heads-up: procps-ng (notably "ps" tool) as a DoS vector

Hello (intentionally primarily) cluster stack development forces, I came around http://www.openwall.com/lists/oss-security/2018/05/17/1 that seems to indicate it is fairly trivial for an unprivileged user on an unpatched and non-hardened Linux system using procps-ng as it's primary package for pro

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 impact,

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 f

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

Re: [ClusterLabs Developers] Error when linking to libqb in shared library

[let's move this to developers list] On 12/02/18 07:22 +0100, Kristoffer Grönlund wrote: > (and especially the libqb developers) > > I started hacking on a python library written in C which links to > pacemaker, and so to libqb as well, but I'm encountering a strange > problem which I don't know

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

Hello, there is certainly whole can of these worms, put first that crosses my mind: performing double (de)compression on two levels of abstraction in the inter-node communication is not very clever, to put it mildly. So far, just pacemaker was doing that for itself under certain conditions, now c

Re: [ClusterLabs Developers] [ClusterLabs] [IMPORTANT] Fatal, yet rare issue verging on libqb's design flaw and/or it's use in corosync around daemon-forking

[developers list subscribers, kindly jump to "Current libqb PR" part] On 22/01/18 11:29 +0100, Jan Friesse wrote: >> It was discovered that corosync exposes itself for a self-crash >> under rare circumstance whereby corosync executable is run when there >> is already a daemon instance around (does

Re: [ClusterLabs Developers] Reference to private bugzillas in commit messages

On 09/01/18 18:24 +, Adam Spiers wrote: > Here are the abbreviations currently used within openSUSE and SUSE: > > > https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines#Current_set_of_abbreviations > > Also see this issue (even if you aren't involved with openSUSE) where I go > i

Re: [ClusterLabs Developers] Reference to private bugzillas in commit messages

On 09/01/18 09:56 -0600, Ken Gaillot wrote: > The acronyms, like any other, you just have to pick up over time with > experience. I'll add the ones I know to the Pacemaker Development > document, which are: > > LFBZ - old Linux Foundation bugzilla for the Linux-HA project - https > ://developerb

Re: [ClusterLabs Developers] Reference to private bugzillas in commit messages

On 09/01/18 10:35 +, Adam Spiers wrote: > Andrei Borzenkov wrote: >> On Tue, Jan 9, 2018 at 11:23 AM, Kristoffer Grönlund >> wrote: >>> Andrei Borzenkov writes: >>> I wonder what is the policy here. commit 7b7521c95d635d8b4cf04f645a6badc1069c6b46 Author: liangxin1300 >

[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: >>

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 t

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] RA as a systemd wrapper -- the right way?

On 07/11/17 02:01 +0100, Jan Pokorný wrote: > On 07/11/17 01:02 +0300, Andrei Borzenkov wrote: >> 06.11.2017 22:38, Valentin Vidic пишет: >>> On Fri, Oct 13, 2017 at 02:07:33PM +0100, Adam Spiers wrote: >>>> I think it depends on exactly what you mean by "synchro

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

On 24/11/17 07:10 +0100, Kristoffer Grönlund wrote: > Jan Pokorný writes: >> Wanted to add a comment on IPaddr vs. IPaddr2 (which, as mentioned, >> boils down to ifconfig vs. iproute2) situation being used for >> comparison -- this is substantially a different story, as ipr

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

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

On 23/11/17 16:54 +0800, Eric Ren wrote: >> What about VolumeGroup (in the tradition of Filesystem, for instance)? > In the LVM-activate, we will support both all VG activation and only > one specified LV activation depending on the parameters. This non-educated suggestion was driven solely by th

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

On 22/11/17 15:28 -0600, David Teigland wrote: > On Wed, Nov 22, 2017 at 03:08:19PM -0600, David Teigland wrote: >> On Wed, Nov 22, 2017 at 02:34:31PM -0600, Chris Feist wrote: >>> lvm2: >>> Good - It's obvious it's a newer/better version of the lvm agent. >>> Bad - It may be associated with the lv

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

[sorry, managed to drop most recent modifications just before sending, fortunately got them from the editor's backups, so skip the previous entry in the thread in favor of this one, also to avoid some typos bleed, please] On 07/11/17 01:02 +0300, Andrei Borzenkov wrote: > 06.11.2017 22:38, Valenti

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

On 07/11/17 01:02 +0300, Andrei Borzenkov wrote: > 06.11.2017 22:38, Valentin Vidic пишет: >> On Fri, Oct 13, 2017 at 02:07:33PM +0100, Adam Spiers wrote: >>> I think it depends on exactly what you mean by "synchronous" here. You can >>> start up a daemon, or a process which is responsible for fork

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

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) subtlet

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ý wrote: >>> So, going to attend summit and want your key signed while reciprocally >>> spreading the web of trust? >>> Awesome, let's reuse the steps f

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

On 03/08/17 18:40 +0200, Valentin Vidic wrote: > On Tue, Aug 01, 2017 at 11:07:24PM +0200, Jan Pokorný wrote: >> https://bugzilla.redhat.com/1477354 > > Thanks for the info. We are seeing similar problems with the > pacemaker build on Debian now: > > https:/

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

On 31/07/17 22:26 +0200, Jan Pokorný wrote: > 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,

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 r

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

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

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

On 23/07/17 12:32 +0100, Adam Spiers wrote: > Jan Pokorný 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: >> >> Once you have a key pair

[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 traditi

[ClusterLabs Developers] Coming in pacemaker: CIB schema versioning no longer compatible with string- and float-based comparisons

Originally, pacemaker was treating versions of its CIB schemas (respectively named files) as floats, simplifying comparisons in a simplistic single-digit minor version realms. As the necessity to roll out a new schema version catering the new needs is around the corner, it was decided[1] that pace

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] 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 pr

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) project, one of most frequent

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 moved

[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] 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] 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] 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

Re: [ClusterLabs Developers] Help! Can packmaker launch resource from new network namespace automatically

[forwarding to users list as it seems a better audience to me] On 22/12/16 05:08 +0800, Hao QingFeng wrote: > I am newbie for pacemaker and using it to manage resource haproxy on ubuntu > 16.04. > > I met a problem that haproxy can't start listening for some services > in vip because the related

[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 n

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

On 03/11/16 19:37 +, Adam Spiers wrote: > Ken Gaillot wrote: >> On 10/21/2016 07:40 PM, Adam Spiers wrote: >>> Ken Gaillot wrote: On 09/26/2016 09:15 AM, Adam Spiers wrote: > For example, could Pacemaker be extended to allow hybrid resources, > where some actions (such as start,

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

On 26/09/16 11:39 -0500, Ken Gaillot wrote: > On 09/26/2016 09:10 AM, Adam Spiers wrote: >> Now, here I *do* see a potential problem. If service B is managed by >> Pacemaker, is configured with Requires=A and After=A, but service A is >> *not* managed by Pacemaker, we would need to ensure that on

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

On 26/09/16 15:15 +0100, Adam Spiers wrote: > [snipped] > > To clarify: I am not religiously defending this "wrapper OCF RA" idea > of mine to the death. It certainly sounds like it's not as clean as I > originally thought. But I'm still struggling to see any dealbreaker. > > OTOH, I'm totally

Re: [ClusterLabs Developers] Resurrecting OCF

On 21/09/16 16:26 -0500, Ken Gaillot wrote: > On 09/21/2016 10:55 AM, Jan Pokorný wrote: >> On 21/09/16 14:50 +1000, Andrew Beekhof wrote: >>> I like where this is going. >>> Although I don’t think we want to get into the business of trying to >>> script conf

[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 sp

Re: [ClusterLabs Developers] Resurrecting OCF

its not a 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

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 long

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: >> On 24/08/16 18:50,

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

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] 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 -&

Re: [ClusterLabs Developers] Resurrecting OCF

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 -> clusterlabs would be similar): > > # (adapt an

Re: [ClusterLabs Developers] Resurrecting OCF

On 18/08/16 17:27 +0200, Klaus Wenninger wrote: > On 08/18/2016 05:16 PM, Ken Gaillot wrote: >> On 08/18/2016 08:31 AM, Kristoffer Grönlund wrote: >>> Jan Pokorný writes: >>> >>>> Thinking about that, ClusterLabs may be considered a brand established >

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 used &

  1   2   >