Hi, Reposting to the zope-dev list - does anyone know if zc.zk is still active? I have another patch to fix importing nodes with spaces in the name, but maybe I should just fork it instead and apply my fixes there. :)
I was using the export_tree method in zc.zk to dump a zookeeper tree today, and some nodes which have no data had garbage data dumped instead of an empty string. I think this is an issue in the underlying zookeeper library, but there is a simple patch to avoid the issue (attached), so if possible it would be nice to see it added in zc.zk.
Here's a link to the patch: https://gist.github.com/davecahill/5539050
Thanks, Dave.
On Tue, May 14, 2013 at 6:02 AM, Dave Cahill <dcahill@midokura.com> wrote:
Hi,
Reposting to the zope-dev list - does anyone know if zc.zk is still active?
Yes, but I have lots of other projects. Don't expect instant responses.
I have another patch to fix importing nodes with spaces in the name, but maybe I should just fork it instead and apply my fixes there. :)
Maybe. Not sure nodes with spaces in the names is a good idea. In terms of plans: - You should only use zc.zk for it's original use cases of service registry and discovery. For anything else, you should use kazoo. - I plan to port zc.zk to kazoo. This hasn't been an urgent priority up to now (although it's been getting more so). I was hoping to get a student to work on it, but that didn't work out. If someone is looking for a project, I'd be happy to have volunteers. :) There are two projects waiting for work: https://github.com/python-zk/zk.fauxzoo This is a replaceable mock, similar to what zc.zk provides. It should allow application tests with or without connection to a ZooKeeper server. https://github.com/python-zk/zk.service This is a port of the functionality in zc,zk that's absent from kazoo, including the high-level data model and service registry and discovery. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton
Hi Jim, Thanks for the response and advice. My use case is purely export / dump (including ephemeral nodes) and load - I looked at kazoo, but it didn't seem to provide that functionality, where zc.zk did. Do you know where the dump/load functionality would fit in future plans? Or if there's a better option for dump and load? I tried a few options (zktreeutil crashed due to long strings, guano had issues with long file names etc).
Maybe. Not sure nodes with spaces in the names is a good idea.
You're right that as a client, putting spaces in node names is not a great idea because many tools don't handle them. But I figure if the client has already written nodes with spaces to Zookeeper, the dump tool should dump them that way instead of failing. Kind of like the robustness principle of "Be conservative in what you send, be liberal in what you accept", the client shouldn't be creating nodes with space names, but the tool will be more robust if it can handle that. As far as I can tell from the docs, spaces are not illegal in ZK path names. Either way, that may be irrelevant if I should be looking elsewhere for dump and load functionality - interested to hear your take. Thanks again for the detailed reply, Dave. On Tue, May 14, 2013 at 9:24 PM, Jim Fulton <jim@zope.com> wrote:
On Tue, May 14, 2013 at 6:02 AM, Dave Cahill <dcahill@midokura.com> wrote:
Hi,
Reposting to the zope-dev list - does anyone know if zc.zk is still active?
Yes, but I have lots of other projects. Don't expect instant responses.
I have another patch to fix importing nodes with spaces in the name, but maybe I should just fork it instead and apply my fixes there. :)
Maybe. Not sure nodes with spaces in the names is a good idea.
In terms of plans:
- You should only use zc.zk for it's original use cases of service registry and discovery. For anything else, you should use kazoo.
- I plan to port zc.zk to kazoo. This hasn't been an urgent priority up to now (although it's been getting more so). I was hoping to get a student to work on it, but that didn't work out.
If someone is looking for a project, I'd be happy to have volunteers. :)
There are two projects waiting for work:
https://github.com/python-zk/zk.fauxzoo
This is a replaceable mock, similar to what zc.zk provides. It should allow application tests with or without connection to a ZooKeeper server.
https://github.com/python-zk/zk.service
This is a port of the functionality in zc,zk that's absent from kazoo, including the high-level data model and service registry and discovery.
Jim
-- Jim Fulton http://www.linkedin.com/in/jimfulton
On Tue, May 14, 2013 at 9:12 PM, Dave Cahill <dcahill@midokura.com> wrote:
Hi Jim,
Thanks for the response and advice.
My use case is purely export / dump (including ephemeral nodes) and load - I looked at kazoo, but it didn't seem to provide that functionality, where zc.zk did.
Do you know where the dump/load functionality would fit in future plans? Or if there's a better option for dump and load? I tried a few options (zktreeutil crashed due to long strings, guano had issues with long file names etc).
I consider import and export of the tree models a core feature that will be ported to zk.service. Keep in mind though that it isn't intended as a general-purpose ZooKeeper export/import facility. I think if you want to export and import arbitrary ZooKeeper data, written by any application, I'd recommend writing something simple that exports and imports to something like marshal, pickle, or json. Writing such a tool should take a few minutes, not count tests, which brings it up to a few hours. ;)
Maybe. Not sure nodes with spaces in the names is a good idea.
This is particularly in the context of zc.zk's service model.
You're right that as a client, putting spaces in node names is not a great idea because many tools don't handle them. But I figure if the client has already written nodes with spaces to Zookeeper, the dump tool should dump them that way instead of failing.
Perhaps. Again, if you want a dump tool that losslessly dumps and loads arbitrary node data, I would use something simpler and less focused than zc.zk's export/import format. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton
participants (2)
-
Dave Cahill -
Jim Fulton