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,
On Fri, 2019-01-18 at 18:53 +0100, Lars Ellenberg wrote:
> On Thu, Jan 17, 2019 at 09:09:11AM +1100, Andrew Beekhof wrote:
> >
> >
> > > 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(),
On Thu, Jan 17, 2019 at 09:09:11AM +1100, Andrew Beekhof wrote:
>
>
> > 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()
> 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.
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.
Pacemaker has about 1,700 logging calls that would be affected
