[
https://issues.apache.org/jira/browse/BOOKKEEPER-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13477088#comment-13477088
]
Ivan Kelly commented on BOOKKEEPER-390:
---------------------------------------
The approach looks good. I have a few comments on the implementation.
Firstly, I think you should get rid of Abortable and rename ZooKeeperWatcher to
ZooKeeperWatcherBase. Then for the the case where you want to so something
special for Expired...
{code}
ZooKeeperWatcherBase w = new ZooKeeperWatcherBase(conf.getZkTimeout()) {
@Override
public void process(WatchedEvent event) {
if (event.getState().equals(Watcher.Event.KeeperState.Expired)) {
LOG.error("ZK client connection to the ZK server has expired!");
isZkExpired = true;
shutdown(ExitCode.ZK_EXPIRED);
} else {
super.process(event);
}
}
};
{code}
In your implementation do you imagine that there'll be more than one
"BookKeeper" user ACL?
If you do think there should be more users, for the implementation of ZkUtils,
I think you don't need #createMyACL. Rather, statically initialize two members
depending on the value of the system property.
{code}
class ZkUtils {
...
ACL CREATOR_ALL_AND_WORLD_READABLE;
ACL CREATOR_ALL;
static {
if (isSecureZooKeeper()) {
CREATOR_ALL = ZooDefs.Ids.CREATOR_ALL_ACL;
...
} else {
CREATOR_ALL = OPEN_ACL_UNSAFE;
...
}
};
}
{code}
Actually, I'd prefer this to be in a ZkAcls class instead of in ZkUtils. It
could be a subclass of ZkUtils, or it's own toplevel.
> Provide support for ZooKeeper authentication
> --------------------------------------------
>
> Key: BOOKKEEPER-390
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-390
> Project: Bookkeeper
> Issue Type: New Feature
> Components: bookkeeper-client, bookkeeper-server
> Affects Versions: 4.0.0
> Reporter: Rakesh R
> Assignee: Rakesh R
> Attachments: BOOKKEEPER-390-Acl-draftversion.patch
>
>
> This JIRA adds support for protecting the state of Bookkeeper znodes on a
> multi-tenant ZooKeeper cluster.
> Use case: When user tries to run a ZK cluster in multitenant mode, where
> more than one client service would like to share a single ZK service instance
> (cluster). In this case the client services typically want to protect their
> data (ZK znodes) from access by other services (tenants) on the cluster. Say
> you are running BK, HBase or ZKFC instances, etc... having
> authentication/authorization on the znodes is important for both security and
> helping to ensure that services don't interact negatively (touch each other's
> data).
> Presently Bookkeeper does not have support for authentication or
> authorization while accessing to ZK. This should be added to the BK
> clients/server that are accessing the ZK cluster. In general it means calling
> addAuthInfo once after a session is established
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
