tturenko, johan.wikman Is this complete - can it be closed ?

This tests lsyncd, not MaxScale.

markus makela johan.wikman tturenko- The task here is to include this in MaxScale system test plan - even if it seems to be testing lsyncd - the impact is on MaxScale. If lsyncd is not configured properly - config changes on one MaxScale will not be propagated to other MaxScale and when failover occurs between MaxScale - the new active MaxScale will not behave like the failed MaxScale. I see this has been closed as Incomplete - what is the plan to complete it.

Since lsyncd is configured by the end-user of MaxScale, what is the purpose of testing that we can configure lsyncd?

Here is the documentation we provide to configure lsynchd for maxscale configuration synching: https://github.com/mariadb-corporation/MaxScale/blob/2.0.1/Documentation/Tutorials/MaxScale-HA-with-lsyncd.md. The purpose of testing is to test integration of MaxScale and lsyncd as per this documentation. System test plan goal is to test MaxScale with the ecosystem of tools that we recommend to users and customers, rather then just MaxScale as standalone - hence the request.

Yes, that makes sense. And should be done once per release.

tested manually: works as described in the documentation. The only additions: EPEL repo is needed to install lsyncd to CentOS/RHEL (but we can refer to some lsyncd installation guide) and user which is used by lsync to access nodes have to have write access to /etc/