Apache ZooKeeper <https://zookeeper.apache.org> is a large dependency. Enabling developers and operations to use etcd <https://etcd.io>, Consul <https://consul.io>, or ZooKeeper should reduce resource utilisation and enable new use cases.
There have already been a number of suggestions to get rid of hard dependency on ZooKeeper. For example, see: MESOS-1806 <https://issues.apache.org/jira/browse/MESOS-1806>, MESOS-3574 <https://issues.apache.org/jira/browse/MESOS-3574>, MESOS-3797 <https://issues.apache.org/jira/browse/MESOS-3797>, MESOS-5828 <https://issues.apache.org/jira/browse/MESOS-5828>, MESOS-5829 <https://issues.apache.org/jira/browse/MESOS-5829>. However, there are difficulties in supporting a few implementations for different services with quite distinct data models. A few months ago offscale.io invested in a solution to this problem - liboffkv <https://github.com/offscale/liboffkv> – a *C++* library which provides a *uniform interface over ZooKeeper, Consul KV and etcd*. It abstracts common features of these services into its own data model which is very similar to ZooKeeper’s one. Careful attention was paid to keep methods both efficient and consistent. It is cross-platform, open-source (*Apache-2.0 OR MIT*), and is written in C++, with vcpkg packaging, *C library output <https://github.com/offscale/liboffkv/blob/d3d549e/CMakeLists.txt#L29-L35>*, and additional interfaces in *Go <https://github.com/offscale?q=goffkv>*, *Java <https://github.com/offscale/liboffkv-java>*, and *Rust <https://github.com/offscale/rsoffkv>*. Offscale.io proposes to replace all ZooKeeper usages in Mesos with usages of liboffkv. Since all interactions which require ZooKeeper in Mesos are conducted through the class Group (and GroupProcess) with a clear interface the obvious way to introduce changes is to provide another implementation of the class which uses liboffkv instead of ZooKeeper. In this case the original implementation may be left unchanged in the codebase and build flags to select from ZK-only and liboffkv variants may be introduced. Once the community is confident, you can decide to remove the ZK-only option, and instead only support liboffkv [which internally has build flags for each service]. Removing the hard dependency on ZooKeeper will simplify local deployment for testing purposes as well as enable using Mesos in clusters without ZooKeeper, e.g. where etcd or Consul is used for coordination. We expect this to greatly reduce the amount of resource—network, CPU, disk, memory—usage in a datacenter environment. If the community accepts the initiative, we will integrate liboffkv into Mesos. We are also ready to develop the library and consider any suggested improvements. *SAMUEL MARKS* Sydney Medical School | Westmead Institute for Medical Research | https://linkedin.com/in/samuelmarks Director | Sydney Scientific Foundation Ltd <https://sydneyscientific.org> | Offscale.io of Sydney Scientific Pty Ltd <https://offscale.io> *SYDNEY SCIENTIFIC FOUNDATION and THE UNIVERSITY OF SYDNEY* PS: We will be offering similar contributions to Chronos <https://mesos.github.io/chronos>, Marathon <https://github.com/mesosphere/marathon>, Aurora <https://github.com/aurora-scheduler/aurora>, and related projects.
