hadoop-zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Hunt (JIRA)" <j...@apache.org>
Subject [jira] Commented: (ZOOKEEPER-237) Add a Chroot request
Date Mon, 01 Jun 2009 20:51:07 GMT

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715249#action_12715249

Patrick Hunt commented on ZOOKEEPER-237:

The current patch implements the java client side of chroot. After reviewing the code more
closely it became clear
that implementing this on the server is much harder/errorprone/inefficient than implementing
the core functionality
on the client. This means we don't get enforcement with this JIRA, however ZOOKEEPER-424 was
created to
address that feature enhancement.

As it currently stands the client can set a chroot during client (ZooKeeper) object creation
which will provide
similar functionality to unix chroot command. See the updated API and forrest docs for details.

I added 3 tests, two of which re-use existing test functionality. I'm validating both the
synchronous as well
as async operations.

Note: I made delete("/") have the same semantics w/ or w/o chroot being used. I thought this
best, although
not strictly necessary.

Note: /zookeeper is only available if chroot is not used (we don't map it into the chroot
for example). I don't think
we would want to do that anyway. but wanted to not it here for review.

When updating the client code I introduced the concept of clientpath and serverpath to make
the distinction more

Note that we validate both the chroot path as well as the clientPath, we don't validate the
serverpath, assuming
that it's valid. Also this ensures that clientpaths start, for example, with / character

Note: watchregistration objects resulted in a very nice way of mapping client/server paths
in watches that don't require
us to do any prefix elimination.

In general I was pretty happy with the (small) number of changes required to implement this
and also the decent
test coverage we currently have.

Mahadev should take this next and implement the c client changes, hopefully they will be similar.

> Add a Chroot request
> --------------------
>                 Key: ZOOKEEPER-237
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-237
>             Project: Zookeeper
>          Issue Type: New Feature
>          Components: c client, java client
>            Reporter: Benjamin Reed
>            Assignee: Patrick Hunt
>            Priority: Minor
>             Fix For: 3.2.0
>         Attachments: ZOOKEEPER-237.patch
> It would be nice to be able to root ZooKeeper handles at specific points in the namespace,
so that applications that use ZooKeeper can work in their own rooted subtree.
> For example, if ops decides that application X can use the subtree /apps/X and application
Y can use the subtree /apps/Y, X can to a chroot to /apps/X and then all its path references
can be rooted at /apps/X. Thus when X creates the path "/myid", it will actually be creating
the path "/apps/X/myid".
> There are two ways we can expose this mechanism: 1) We can simply add a chroot(String
path) API, or 2) we can integrate into a service identifier scheme for example zk://server1:2181,server2:2181/my/root.
I like the second form personally.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message