Patrick Hunt commented on ZOOKEEPER-237:
credential: how about binding the id then?
acl use: I was thinking that some users might use this instead of acls -
similar to the way aws does
So you are saying then that this is purely a user space feature. Clients can
set this for their own convenience, but it has no aspirations towards being a
In which case an ops team might assign a client a particular subtree
"/apps/app1", they would configure the ACLs such that the "app1" client would
only have access to /apps/app1. The client would then have the ability to
"chroot" to /apps/app1 (hopefully using the second form you list above) and
therefore skip the need to prefix all paths with /apps/app1. That sounds fine.
Another benefit is that if the client has to move to a diff part of the
heirarchy, this could be done by changing the connection string (chroot) alone.
> Add a Chroot request
> Key: ZOOKEEPER-237
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-237
> Project: Zookeeper
> Issue Type: New Feature
> Reporter: Benjamin Reed
> Priority: Minor
> 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
> 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.