Netdata Community

ACLK-NG Heads Up For Maintainers

Hi, this post is meant as heads-up for package maintainers.

As the Cloud connectivity component called ACLK has been disabled in most packages due to us bundling libraries we have been working on a new implementation of this component.

The new implementation of ACLK relies only on JSON-C and OpenSSL (both as shared libs, not bundled).

This should remove blockers preventing ACLK/Cloud functionality to find it’s way to 3rd party/distribution packages.

Please be aware that even with the ACLK component built Netdata will not connect to Cloud at all unless explicitly asked to do so by the administrator (by the process of Claiming).

This is in PR state and should be merged within the following weeks. First as a fallback mechanism (if ACLK Legacy cannot be built) and when we are certain of its maturity and stability as a default mechanism of Agent<->Cloud connection (if everything goes well legacy ACLK will be obsoleted eventually).

2 Likes

Hello,

ACLK-NG has been merged to master and is in current nightlies and next full/stable release. Currently, it operates as a fallback in the case where ACLK Legacy can’t be built (e.g. due to missing dependency).
It is however possible to enforce the use of new ACLK NG by passing --aclk-ng flag to the installer.

After ACLK-NG is seen as working well also by our users ACLK Legacy will be removed and ACLK-NG will become default (and only) implementation of ACLK in the netdata agent.

4 Likes

That’s awesome @underhood !

So now if we build the Netdata Agent with the -aclk-ng flag, there won’t be any dependencies with vendored libraries. Thus removing the last blocker most Linux distributions had in regards to netdata packaging and building with Netdata Cloud support.

Yes indeed ACLK-NG depends only on OpenSSL and JSON-C both of which are used as regular system shared libs.

In the following days the behavior is to be switched from:
default Legacy, ACLK-NG fallback
to:
ACLK-NG as default and Legacy as fallback