[ClusterLabs] Corosync 3 release plans?

[Jan Friesse]

Ferenc,

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

Agree

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

For this we would need support from libqb which (AFAIK) still doesn't 
support highres timestamps.

> file log only, not for syslog (by default).  And log file reopening

timestamp doesn't affect blackbox and/or syslog.

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

Anyway, this again one of the feature where support from libqb would be 
nice to have (there is actually issue opened 
https://github.com/ClusterLabs/libqb/issues/239).

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

Yep

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

Yep (and PR send + merged already :) )

Regards,
   Honza

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