rs / zkfarmer Goto Github PK

/usr/lib/python2.6/site-packages/zkfarmer-1.1.0-py2.6.egg/EGG-INFO/scripts/zkfarmer:180: DeprecationWarning: Passing retry configuration param max_retries to the client directly is deprecated, please pass a configured retry object (using param max_tries)
zkconn = KazooClient(args.host, max_retries=5)

non-fatal info warning.

kazoo-1.3.1, the latest tagged version on github.

KazooClient expects a KazooRetry object for the param connection_retry

code:

from kazoo.retry import KazooRetry

zkretries = KazooRetry(max_tries=3)
zkconn = KazooClient(args.host, connection_retry=zkretries)

• Editing /var/service/db/enabled with "vi" creates a binary .swp file in /var/service/db
• zkfarmer tries to serialize it along with other files and fails, returning {}
• all files in /var/service/db are instantly wiped, removing all fields from ephemeral node in ZK

Using zkfarmer for third-party software registration for our project. It's working great except for one strange thing. Hit this issue a couple of times. The behavior is as following:

zkfarmer connects to zookeeper successfully and runs for some without a problem. Then (according to the logs from one of the zookeeper nodes) one node goes unreachable. Which means the quorum is broken since we have only 3 nodes (5 ideally advised by zookeeper at the moment). zookeeper stays reachable overall - using load balancer link to access it. The third node quickly gets back (maybe 10 minutes overall). And zkfarmer does not report any connection drop or any problem nowhere in the logs (I'm watching over zkfarmer process). So it's there and it thinks it is still connected to zookeeper while in fact it's not. If you go to zookeeper you won't be able to find an ephemeral node, which is an obvious indication that zkfarmer is not connected.