[ClusterLabs] Corosync 3 release plans?

[Ken Gaillot]

On Thu, 2018-09-27 at 09:58 -0500, Ken Gaillot wrote:
> On Thu, 2018-09-27 at 15:32 +0200, Ferenc Wágner wrote:
> > Christine Caulfield <ccaulfie at redhat.com> writes:
> > 
> > > TBH I would be quite happy to leave this to logrotate but the
> > > message I
> > > was getting here is that we need additional help from libqb. I'm
> > > willing
> > > to go with a consensus on this though
> > 
> > Yes, to do a proper job logrotate has to have a way to get the log
> > files
> > reopened.  And applications can't do that without support from
> > libqb,
> > if
> > I understood Honza right.
> 
> There are two related issues:
> 
> * Issue #142, about automatically rotating logs once they reach a
> certain size, can be done with logrotate already. If it's a one-time
> thing (e.g. running a test with trace), the admin can control
> rotation
> directly with logrotate --force /etc/logrotate.d/whatever.conf. If
> it's
> desired permanently, a maxsize or size line can be added to the
> logrotate config (which, now that I think about it, would be a good
> idea for the default pacemaker config).
> 
> * Issue #239, about the possibility of losing messages with
> copytruncate, has a widely used, easily implemented, and robust
> solution of using a signal to indicate reopening a log. logrotate is
> then configured to rotate by moving the log to a new name, sending
> the
> signal, then compressing the old log.

Regarding implementation in libqb's case, libqb would simply provide
the API for reopening the log, and clients such as pacemaker would
intercept the signal and call the API.

A minor complication is that pacemaker would have to supply different
logrotate configs depending on the version of libqb available.
-- 
Ken Gaillot <kgaillot at redhat.com>