- Only use zake in unit-tests by providing a client to the backend as a fake client. This avoids cases where a real client should be provided; and if not provided then a error should be thrown. This avoids potential misuse of zake (which really is only designed for testing usage and not for actual usage in production). - Add a kazoo_utils file that will be shared to make kazoo clients and to parse hosts into a kazoo friendly format for other usages of kazoo clients that will be appearing soon. - Ensure basic assertions when creating the zk backend, don't allow empty paths, require absolute paths. - Update exc_wrapper to have slightly more descriptive messages that identify more of what the original errors category was. - Create initial paths on upgrade() to mirror what other backends are doing in their upgrade() function. Other backends do their initial steps to upgrade there backends in this function (ie sqlalchemy does its migrations here so it seems to be consistent place to make sure zookeeper paths are created correctly). Change-Id: Iabafe73c059b4719617f01bd1ee35795f71ca21d
10 lines
140 B
Plaintext
10 lines
140 B
Plaintext
hacking>=0.8.0,<0.9
|
|
discover
|
|
coverage>=3.6
|
|
mock>=1.0
|
|
testrepository>=0.0.17
|
|
testtools>=0.9.32,<0.9.35
|
|
# ZooKeeper
|
|
kazoo>=1.3.1
|
|
zake>=0.0.13
|