Control: tags -1 - moreinfo "Adam D. Barratt" <a...@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
