[ClusterLabs] Corosync 3 release plans?

Jan Friesse jfriesse at redhat.com
Mon Sep 24 08:48:53 EDT 2018


> Jan Friesse <jfriesse at redhat.com> writes:
>> Have you had a time to play with packaging current alpha to find out
>> if there are no issues? I had no problems with Fedora, but Debian has
>> a lot of patches, and I would be really grateful if we could reduce
>> them a lot - so please let me know if there is patch which you've sent
>> PR for and it's not merged yet.
> Hi Honza,
> Sorry for the delay.  You've already merged my PR for two simple typos,

no worries

> thanks!  Beyond that, there really isn't much in our patch queue
> anymore.  As far as I can see, current master even has a patch for error
> propagation in notifyd, which will let us drop one more!  And we arrive
> at the example configs.  We prefer syslog for several reasons
> (copytruncate rotation isn't pretty, decoupling possible I/O stalls) and
> we haven't got the /var/log/cluster legacy.  But more importantly, the
> knet default transport requires a nodelist instead of interfaces, unlike
> mcast udp.  The "ring" terminology might need a change as well,
> especially ring0_addr.  So I'd welcome an overhaul of the (now knet)
> example config, but I'm not personally qualified for doing that. :)

Yes, that's really good catch, because I've totally forgot this two files.

Default example config should be definitively ported to newer style of 
nodelist without interface section. example.udpu can probably be deleted 
as well as example.xml (whole idea of having XML was because of cluster 
config tools like pcs, but these tools never used corosync.xml).

I was also thinking about allowing timestamp by default, because log 
without timestamp is useless.

> Finally, something totally unrelated: the libtotem_pg shared object
> isn't standalone anymore, it has several undefined symbols (icmap_get_*,
> stats_knet_add_member, etc) which are defined in the corosync binary.

This must be fixed.

> Why is it still a separate object then?

Honestly, I don't have too much strong reasons. We've talked with 
Chrissie about it last year, and actually only reason I was able to find 
out was to have a code/component separation so in theory other project 
can use totem (what was original idea, but it never happened and I don't 
think it will ever happen). Anyway, conclusion was to remove the totem 
as a shared library and keep it as a static library only, but nobody 
actually implemented that yet.

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

Thank you for the testing and reporting problems!


More information about the Users mailing list