[ClusterLabs] Corosync 3 release plans?

[Ferenc Wágner]

Jan Friesse <jfriesse at redhat.com> writes:

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

Kind of strange, because the inherently hierarchical Corosync
configuration admits a very natural XML representation.

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

I recommend adding high resolution timestamps, even, but for the direct
file log only, not for syslog (by default).  And log file reopening
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.

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

Or rather eliminated, if I read correctly below.

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

That doesn't buy you anything if you use it in a single binary only.

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

> Thank you for the testing and reporting problems!

My pleasure, speaking about the latter.  I haven't got to do any
significant testing yet, unfortunately.
-- 
Regards,
Feri