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

> On 17 Jan 2019, at 2:59 am, Ken Gaillot wrote: > > I'm not familiar with the reasoning for the current setup, but > pacemaker's crm_crit(), crm_error(), etc. use qb_logt(), while > crm_debug() and crm_trace() (which won't be used in ordinary runs) do > something similar to what you propose.

Re: [ClusterLabs Developers] Resurrecting OCF

I like where this is going. Although I don’t think we want to get into the business of trying to script config changes from one agent to another, so I’d drop #4 I would make .deprecated a nested directory so that if we want to retire (for example) a ClusterLabs agent in the future we can

Re: [ClusterLabs Developers] Potential logo for Cluster Labs

> On 26 Aug 2016, at 1:48 AM, Digimer wrote: > > On 25/08/16 11:35 AM, Kristoffer Grönlund wrote: >> Digimer writes: >> >>> >>> My first reaction was "Meh, I like Ken's idea better". But they it >>> started to sink in and I have to agree, I love it too.

Re: [ClusterLabs Developers] OCF under the Linux Foundation?

I’d just be cautious about giving them the keys to anything. It took many months for them to bring their bugzilla instance back online and we lost many years of bug data. Another consideration, between ourselves we can make decisions pretty constructively and quickly… is a layer of red tape

Re: [ClusterLabs Developers] OCF_RESKEY_CRM_meta_notify_active_* always empty

Sent from my iPhone > On 30 Jul 2016, at 8:32 AM, Ken Gaillot wrote: > > I finally had time to investigate this, and it definitely is broken. > > The only existing heartbeat RA to use the *_notify_active_* variables is > Filesystem, and it only does so for OCFS2 on

Re: [ClusterLabs Developers] OCF_RESKEY_CRM_meta_notify_active_* always empty

;kgail...@redhat.com> wrote: > >> On 07/29/2016 05:41 PM, Andrew Beekhof wrote: >> >> >> Sent from my iPhone >> >>> On 30 Jul 2016, at 8:32 AM, Ken Gaillot <kgail...@redhat.com> wrote: >>> >>> I finally had time to investigate this,

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

> On 5 Dec 2015, at 4:22 AM, Ken Gaillot wrote: > > On 12/04/2015 10:59 AM, Jan Pokorný wrote: >> Btw. was any other architectural approach considered? It's sad >> that multiplatform IPC, which is what might be better to handle >> more or less continuous one-way stream of

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

luster events, as described by Andrew Beekhof on That > Cluster Guy blog: > http://blog.clusterlabs.org/blog/2015/reliable-notifications/ > > For a future version, we're considering extending that to allow multiple > notification scripts, each with multiple recipients. This would

Re: [ClusterLabs Developers] migrate-to and migrate-from for moving Master/Slave roles ?

> On 26 Nov 2015, at 11:52 AM, Jehan-Guillaume de Rorthais > wrote: > > Hi guys, > > While working on our pgsqlms agent[1], we are now studying how to control all > the steps of a switchover process from the resource agent. > > The tricky part here is the 2nd step of a

Re: [ClusterLabs Developers] --verbose breaks stonithd + some fencing agents

> On 15 Oct 2015, at 12:10 PM, Adam Spiers wrote: > > Hi all, > > I'm certainly no expert on stonithd or the way it interfaces with > fence-agents, but I think I found a bug in either stonithd or > fencing.py. > > If a fencing agent is invoked with the --verbose CLI argument