Bug#950488: buster-pu: package kronosnet/1.8-2
Control: tags -1 - moreinfo
"Adam D. Barratt" <adam@adam-barratt.org.uk> writes:
> Apologies for not replying sooner.
No problem. I was starting to accept that my request was so outlandish
that it didn't even warrant a reply. :)
> On Sun, 2020-02-02 at 14:47 +0100, Ferenc Wágner wrote:
>> I'v got a bold request: please let me update Kronosnet in buster from
>> 1.8-2 to 1.13-something to fix #946222. During the buster freeze
>> period, upstream released 1.9 and 1.10, but those didn't bring
>> important
>> fixes, so I didn't request freeze exceptions for them. However, when
>> Proxmox VE 6.0 got released (based on Debian buster), their users
>> reported lots of intertwined bugs, and the developers iterated
>> through
>> 1.11, 1.12 and 1.13 in quick succession to fix them, see the linked
>> https://forum.proxmox.com/threads/pve-5-4-11-corosync-3-x-major-issues.56124.
>
> Do upstream have a stable or LTS tree? I see that unstable currently
> contains 1.15, so 1.X is presumably not it.
Actually it is. Even 1.16 was released on Thursday from the stable1
branch, I just haven't got around uploading it yet. The master branch
contains bigger changes targeting a future Kronosnet 2.
> Usually when considering a larger update, we'd be looking for
> information such as:
>
> - What sort of changes get included in upstream releases? Are they just
> bug fixes, or are there new features included, or other changes?
The bulk is bug fixes, but there are occasional feature changes as well.
Besides man page improvements and improved error reporting, ACL and zstd
support was added in 1.10, for example. I didn't deem those worth a
freeze exception, though. 1.11 to 1.13 focused on fixing PMTU
discovery, and this is the main reason for this stable update request,
but meanwhile added a new API and musl support (the ABI remained
stable). I linked to the above release announcements in the message
opening this bug, but here are the later ones, too:
1.14 https://lists.kronosnet.org/pipermail/users/2020-January/000025.html
All fixes. Sounds useful, even though the most serious part does not
affect the stock buster kernels.
1.15 https://lists.kronosnet.org/pipermail/users/2020-March/000026.html
All fixes. Nice to have, but not critical unless your application
gathers statistics.
1.16 https://lists.kronosnet.org/pipermail/users/2020-April/000027.html
Fixes a special SCTP case. But also contains some code reorganization,
to fix build issues under GCC 10. Otherwise, it's meant to be a no-op, as
https://github.com/kronosnet/kronosnet/pull/301#issuecomment-620515274
explains in detail.
> - What sort of testing do the new releases get? Is the testing
> automated?
Yes, https://ci.kronosnet.org/ runs across the full Kronosnet - Corosync
- Pacemaker stack, so correct operation is ensured on a basic level.
The maintainers also run more complicated tests on large clusters on a
regular basis (it's an official RedHat project with dedicated staff).
HA cluster setups are very diverse, though, and the failures they are
designed to mitigate are even more so. This is why the past releases
had to concentrate on fixing various connectivity recovery scenarios.
> - What sort of regressions are reported against new releases? How
> quickly are they resolved?
There aren't many. The developer team is active and responsive, see
https://github.com/kronosnet/kronosnet/issues/218 for example. The
cooperation with Corosync (only known user of Kronosnet) is fluid, they
are managed under the same umbrella. The above report came from
Proxmox, a company specializing in HA virtualization (based on Debian).
They were the main driving force behind the 1.11-1.13 updates, seeking
to provide support for their customers. Since they upgraded to 1.13,
things calmed down; they're sitting at 1.14 since February as far as I
can see (https://git.proxmox.com/?p=kronosnet.git).
Hope it answers your questions, just flip back the moreinfo tag if not.
Meanwhile I'll upload 1.16 to unstable.
--
Feri
Reply to: