The main benefit of using this module is if you have several different toolsin your network that all need to interact with Zookeeper in a common way. Themost common functions are handled in this singular module allowing you to focuson your own app development more.

The KazooServiceRegistry object is a child of nd\_service\_registry thatconforms to our ServiceRegistry specs, while leveraging Kazoo as the backend.The object handles all of your connection states - there is no need tostart/stop or monitor the connection state at all.

### Registering Data

#### Ephemeral Nodes

Registering a node in Zookeeper thats Ephemeral (disappears when the nodegoes offline, or if the connection is lost) is highly useful for keepingtrack of which servers are offering specific services.

We initially wrote this code to simplify our use of Zookeeper in Django.Included is a very simple Django utility package that makes it dead simpleto use Zookeeper inside Django for retreiving information. To use, addthe following to your *settings* module in Django:

Warning: LC\_ALL and LANG settings Due to an unknown bug, if Django cannot find your LC\_ALL LOCALE settings (which often default to 'C'), *nd_service_registry* or *kazoo* crash and burn during the init phase. Its unknown why at this point, but we've found that its best to *unset LC\_ALL* and set *LANG=en_US:UTF-8* (or some other valid setting) before you start up your Django app.

If you use Celery, set these options in */etc/default/celeryd*.

If you use uWSGI, set them in your uWSGI config file.

Running the Django shell

# unset LC_ALL; LANG=en_US:UTF-8 python manage.py shell

## Connection Handling

The ServiceRegistry object tries everything that it can to make sure thatthe backend Zookeeper connection is always up and running.

### Fork Behavior

In the event that your code has created an ServiceRegistry object but thengone and forked the process (celery, as an example), we do our best todetect this and re-create the connection, watchers and registrations.

When we detect a fork (more on that below), we re-create our Zookeeperconnection, and then re-create all Watcher and Registration objects as well.

### Fork Detection

Detecting the fork is extremely tricky... we can only really detect it whenyou call the module for new data. This means that if you have created aWatcher or Registration object, those objects will not be aware of the fork(and thus the loss of their connection to Zookeeper) until you make anothercall to them.

Because of this, I strongly recommend that if you can detect the fork fromwithin your application (Django signals perhaps?), you should immediately callthe *rebuild()* method on your ServiceRegistry object.

The goal of this module is to be as self-contained as possible and requireas little code in your app as possible. To that end, we *almost never* raisean Exception once the module is loaded up and connected.

We do raise a few exceptions, and each one is documented here. Whenever wecan though, we instead just *return False* as a way of indicating that we wereunable to perform your command now ... but that we will take care of it later.Whenever we do this, we throw a WARNING log message as well.

### nd\_service\_registry.exceptions.NoConnection

Thrown if you attempt any operation that requires immediate access to thebackend Zookeeper service. Either a *set()* operation, or a *get()*operation on a path for the first time.

Also thrown during initial connection to Zookeeper, if *lazy=False*.

(It should be noted, a *get()* will actually return the cached results evenif Zookeeper is down. This allows the service to fail temporarily in thebackground but your app is still able to get the *last known* results.)

### nd\_service\_registry.exceptions.ReadOnly

If *readonly=True*, any operation that would result in a *write* will throwthis exception. Most notably, a *set()* operation will fail with thisexception if *readonly=True*.

## API Documentation

Detailed implementation details and instructions are in the individuallibrary files.