[ClusterLabs] Corosync 3 release plans?
ccaulfie at redhat.com
Thu Sep 27 03:18:40 EDT 2018
On 26/09/18 09:21, Ferenc Wágner wrote:
> Jan Friesse <jfriesse at redhat.com> writes:
>> wagner.ferenc at kifu.gov.hu writes:
>>> triggered by your favourite IPC mechanism (SIGHUP and SIGUSRx are common
>>> choices, but logging.* cmap keys probably fit Corosync better). That
>>> would enable proper log rotation.
>> What is the reason that you find "copytruncate" as non-proper log
>> rotation? I know there is a risk to loose some lines, but it should be
>> pretty small.
> Yes, there's a chance of losing some messages. It may be acceptable in
> some cases, but it's never desirable. The copy operation also wastes
> I/O bandwidth. Reopening the log files on some external trigger is a
> better solution on all accounts and also an industry standard.
>> Anyway, this again one of the feature where support from libqb would
>> be nice to have (there is actually issue opened
> That's a convoluted one for a simple reopen! But yes, if libqb does not
> expose such functionality, you can't do much about it. I'll stay with
> syslog for now. :) In cluster environments centralised log management is
> a must anyway, and that's annoying to achieve with direct file logs.
I'm looking into new features for libqb and the option in
looks like a good option to me. Though adding an API call to re-open the
log file could be done too - I'm not averse to having both,
>>> Jan Friesse <jfriesse at redhat.com> writes:
>>>> No matter how much I still believe totemsrp as a library would be
>>>> super nice to have - but current state is far away from what I would
>>>> call library (= something small, without non-related things like
>>>> transports/ip/..., testable (ideally with unit tests testing corner
>>>> cases)) and making one fat binary looks like a better way.
>>>> I'll made a patch and send PR (it should be easy).
>>> Sounds sensible. Somebody can still split it out later if needed.
>> Yep (and PR send + merged already :) )
> Great! Did you mean to keep the totem.h, totemip.h, totempg.h and
> totemstats.h header files installed nevertheless? And totem_pg.pc could
> go as well, I guess.
More information about the Users