-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
All,
We are pleased to announce the general availability of kronosnet v1.1
kronosnet (or knet for short) is the new underlying network protocol
for Linux HA components (corosync), that features ability to use
multiple links between nodes, active/active and active/passive link
failover policies, automatic link recovery, FIPS compliant encryption
(nss and/or openssl), automatic PMTUd and in general better
performances compared to the old network protocol.
Highlights in this release:
* Fix plugins loader by switching from RPATH to RUNPATH
* Man pages are now automatically generated at build time
* Better error reporting from crypto plugins
* Fix and improve the whole build system
* Add support for some older lz4 versions
* Fix issue with UDP sockets that could cause knet to spin
* Add new API call to run knet unprivileged
Known issues in this release:
* When configuring compression plugins, the compress_level checks are
not always aligned with what the underlying library can really do.
This has been discussed over the devel mailing list and will be fixed
in libknet 1.2. Only compression advanced users might notice this
problem.
* Tarballs downloaded directly from github will fail to build
(https://github.com/kronosnet/kronosnet/issues/133) please use the
official release tarballs or git clone.
The source tarballs can be downloaded here:
https://www.kronosnet.org/releases/
Upstream resources and contacts:
https://kronosnet.org/https://github.com/kronosnet/kronosnet/https://ci.kronosnet.org/https://trello.com/kronosnet (TODO list and activities tracking)
https://goo.gl/9ZvkLS (google shared drive with presentations and
diagrams)
IRC: #kronosnet on Freenode
https://lists.kronosnet.org/mailman/listinfo/usershttps://lists.kronosnet.org/mailman/listinfo/develhttps://lists.kronosnet.org/mailman/listinfo/commits
Cheers,
The knet developer team
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJakkMqAAoJEAgUGcMLQ3qJfEoQALFAOk+znEqv4ogrGeD22VeT
OL0ihimnW+lW9RjTe04B0VFPonAKFPZ3NmQ9XngaX+XSyvm6NCujpz9LckPc30WZ
MYwD5LJcmeHqHUNfmLTX0wuvkoairiKQNtak26e+6Bt7wfTZ8fzKF3eFKrfJQ8w7
AvBOL8WVzR4v6Jc21/X2IZN1Bn7y2mIJTfnDPwNxFxNi6mfOLkA+OAc9ivjQZADe
XPl0sqzBaaRxg9DrI4XgQxkV1sdwQ6elpL/jd+jKiQ8CfX8zOr6FX7SXTpnbwbmS
2OMzWPCXYxSiJUKWGpJtzn9QkHNrTpDiP3mDQ6KCEEt3o/XXSfkFI/bTuvTtuc/n
R+ki/KhT2FqU/ZmgDmFQmHn1r7r70c/8i8i2GC1+FVYN63rGlofCroY3KZjvFewY
sYLQKXm4zCvR5BZnonpTz2Mf/ISTNzCuaDwxIJKXAO+ksuot8uU54uBiYf4mR/Uu
FuSSaNmiLHYqmEjVHF7V8c7gA4az7gYSV77oNP/y6bECxSrVA0NmXAraYzoIwG01
WsPEobZ4UXRYWggTu16G+xP8EpUiyxDtaJsTy/Kgp5qMqY1aRr5s4u7A6k3/M+HH
ZdFtr5V2dGlR8cqYbkVt4Uayw2UgAULTeNsTGTPgNl5woboKAkomTkWUnh2pAbey
wbPF6bQBtMDasmaPideX
=zqHY
-----END PGP SIGNATURE-----
All,
as subject, I think 1.1 is ready to ship. I am planning to cut a release
over the weekend unless anybody has any pending work that needs to merge
right away.
Cheers
Fabio
Hey guys,
original discussion started here (for reference):
https://github.com/kronosnet/kronosnet/pull/128
int knet_handle_compress(knet_handle_t knet_h,
struct knet_handle_compress_cfg *knet_handle_compress_cfg);
Where knet_handle_compress_cfg contains int compress_level.
As you can see from libknet.h and relative code, we try (too hard) to
validate the values for compress_level.
Feri had a proper concern about applying incorrect filtering and I agree
that it is already becoming complex to maintain a matrix of valid
values, per plugin, per plugin-version, and whatever combination.
AFAIR all plugins accept an int value for compress_level so from that
perspective it shouldn´t be too much of a problem (aka no API/ABI changes).
Historically, the reason why I added the validation was lzo2, that
presents a rather unusual compress configuration vs all other plugins
(as you can see).
I think Feri´s suggestion to drop the filter completely might be too
much, instead, after thinking a bit, it might be perfectly reason to
change the internals of val_level to try and compress a small buffer to
test that the value is good.
The val_level is used only at configuration time, so it´s not too
expensive to compress one small data chunk for validation and it would
remove the whole hardcoded filter of different compress_levels.
For special plugins like lzo2, I think it´s important we improve the
logging at configuration time to make sure users at least warned of
supported values (as you can see each values map to a specific lzo2 API
call to compress).
wdyt?
Fabio
All,
experimenting a bit here. As you build PR for master, please do NOT
create a new PR for stable1. Indicate if the commit qualifies for
stable1 and if we all agree it should be backported, you can or we will
cherry-pick the fix in stable1-proposed branched.
there is a PR open to merge stable1-proposed that will keep running CI
on each cherry-pick backport for now, and we feel the time is ready to
cut 1.1, we will just merge that PR at once.
Cheers
Fabio
All,
We are pleased to announce the general availability of kronosnet v1.0
kronosnet (or knet for short) is the new underlying network protocol
for Linux HA components (corosync), that features ability to use
multiple links between nodes, active/active and active/passive link
failover policies, automatic link recovery, FIPS compliant encryption
(nss and/or openssl), automatic PMTUd and in general better
performances compared to the old network protocol.
The source tarballs can be downloaded here:
https://www.kronosnet.org/releases/
Upstream resources and contacts:
https://kronosnet.org/https://github.com/kronosnet/kronosnet/https://ci.kronosnet.org/https://trello.com/kronosnet (TODO list and activities tracking)
https://goo.gl/9ZvkLS (google shared drive with presentations and
diagrams)
IRC: #kronosnet on Freenode
https://lists.kronosnet.org/mailman/listinfo/usershttps://lists.kronosnet.org/mailman/listinfo/develhttps://lists.kronosnet.org/mailman/listinfo/commits
Known issues in this release:
* Knet will fail to work on Fedora 26 arm when built with clang. This is
a known issue with clang compiler that is fixed in more recent
versions of clang.
* Knet will fail to build with clang on rhel7 + epel version of clang.
This is a known issue with clang compiler that is fixed in more recent
versions of clang.
* Running the knet test suite with valgrind (make check-memcheck) will
fail with Debian Experimental glibc due to a known bug in valgrind.
* Running the knet test suite with valgrind on FreeBSD is no longer
supported. The valgrind version on FreeBSD is too old and generates
too many false positives. Also, please refer to build-aux/check.mk on
how to use valgrind in combination with knet. Some platforms requires
extra options to work properly.
* If you are planning to develop plugins, please be aware of this issue:
https://github.com/kronosnet/kronosnet/issues/107 . It affects only
development environments.
Cheers,
The knet developer team
All,
We are pleased to announce the second public release candidate of
kronosnet v1.0 - which we are calling v0.9
kronosnet (or knet for short) is the new underlying network protocol for
Linux HA components (corosync), that features ability to use multiple
links between nodes, active/active and active/passive link failover
policies, automatic link recovery, FIPS compliant encryption (nss and/or
openssl), automatic PMTUd and in general better performances compared to
the old network protocol.
The source tarballs can be downloaded here:
https://www.kronosnet.org/releases/
Upstream resources and contacts:
https://kronosnet.org/https://github.com/kronosnet/kronosnet/https://ci.kronosnet.org/https://trello.com/kronosnet (TODO list and activities tracking)
https://goo.gl/9ZvkLS (google shared drive with presentations and diagrams)
IRC: #kronosnet on Freenode
https://lists.kronosnet.org/mailman/listinfo/usershttps://lists.kronosnet.org/mailman/listinfo/develhttps://lists.kronosnet.org/mailman/listinfo/commits
Known issues in this release:
* Knet will fail to work on Fedora 26 arm when built with clang. This is
a known issue with clang compiler that is fixed in more recent
versions of clang.
* Knet will fail to build with clang on rhel7 + epel version of clang.
This is a known issue with clang compiler that is fixed in more recent
versions of clang.
* Applications performing configuration changes might experience a long
waiting time when calling into the knet API. This is a known
interaction issue between the PMTUd thread inside knet and external
API locking.
https://trello.com/c/uPMjKRYy/847-fix-pmtud-locking-with-external-api
* Running the knet test suite with valgrind (make check-memcheck) will
fail with Debian Experimental glibc due to a known bug in valgrind.
* Running the knet test suite with valgrind on FreeBSD is no longer
supported. The valgrind version on FreeBSD is too old and generates
too many false positives. Also, please refer to build-aux/check.mk on
how to use valgrind in combination with knet. Some platforms requires
extra options to work properly.
Cheers,
The knet developer team
Hey Chrissie,
I am still having issues with the latest pmtu code:
1) using crypto, just with knet_bench ping_data test, the MTU changes on
each run (I think you mentioned that on IRC, but not sure it's the same
problem).
2) there is a spurious link down event on MTU change. I can reproduce
this one without crypto and with ping_data test (I set it at 10 secs
interval to avoid waiting minutes).
Start knet_bench on both nodes with standard MTU at 1500. At the end of
each run, change MTU on the interfaces to:
- 1400 (good).
- 1500 (good).
- 1600 (good, mtu doesn't change)
- back to 1500 (link down event)
from time to time, the first MTU after the down/up event is wrong
the code is stable on heavy load, I haven't tested yet load + changing
MTU at runtime. I'll do that once the basic tests are passing.
Cheers
Fabio
Hi guys,
we have one PR open (plugins/modules) and one bug fix (PMTUd) pending.
We will complete the merge of both and we will not accept any more
changes for 0.9 RC.
Between 0.9 and 1.0 we will only accept critical bug fixes. Any other
change is 2.0/1.1 material.
Cheers
Fabio
Hey Feri,
let me stop you a minute here.
what is the end goal of this work? We originally didn´t implement the
modules model because it has several downsides for little benefit, based
on the experience we had with corosync modules in the past.
I think it might be beneficial to have a chat about those major changes
before you implement them :-) I *hate* for people to waste time on stuff
that might not merge.
Cheers
Fabio
On 11/28/2017 8:07 AM, GitHub wrote:
> Branch: refs/heads/modules
> Home: https://github.com/kronosnet/kronosnet
> Commit: a2f08e189c0143381f9f3ac5031d6b5dd32f5432
> https://github.com/kronosnet/kronosnet/commit/a2f08e189c0143381f9f3ac5031d6…
> Author: Ferenc Wágner <wferi(a)debian.org>
> Date: 2017-11-28 (Tue, 28 Nov 2017)
>