curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory Chanan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CURATOR-221) ACLProvider is not respected on parent nodes after calling CuratorFramework.usingNamespace
Date Mon, 18 May 2015 22:09:00 GMT

    [ https://issues.apache.org/jira/browse/CURATOR-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14549348#comment-14549348
] 

Gregory Chanan commented on CURATOR-221:
----------------------------------------

I don't necessarily think the behavior is unreasonable.  For example, if those parent nodes
already existed, I probably wouldn't want them to have their ACLs changed.

That said, it was surprising to me that doing operations on CuratorFramework with an ACLProvider
specified resulted in nodes being created that didn't use the ACLProvider.  Perhaps there
could be some configuration about what to do wrt ACLs for implicitly created parent nodes
in Namespaces?  e.g. usingNamespace(path, boolean useACLsIfCreatingParents) or usingNamespace(path).useACLsIfCreatingParents(true)

bq. Can you create the namespace root separately

Yes, although in my case it's a bit complicated.  If you look at HADOOP-11973, to keep the
external vs internal client impl similar, I want to initialize the final CuratorFramework
object in the constructor, which means I want to use the namespace-aware version.  So, I could
create the nodes before I call usingNamespace, but then I have to deal with exception handling,
which I don't want to do in the constructor.  So essentially I have to do:
- call usingNamespace(ns) in the constructor
- in startThreads, call usingNamespace(null) and then create the parents manually.
That seems clunkier than specifying what I want to happen with the parents on the namespace
itself.



> ACLProvider is not respected on parent nodes after calling CuratorFramework.usingNamespace
> ------------------------------------------------------------------------------------------
>
>                 Key: CURATOR-221
>                 URL: https://issues.apache.org/jira/browse/CURATOR-221
>             Project: Apache Curator
>          Issue Type: Bug
>          Components: Framework
>    Affects Versions: 2.7.1
>            Reporter: Gregory Chanan
>
> See HADOOP-11973 for some background information.
> Here's a high level overview of the issue I'm seeing:
> 1) I create a CuratorFramework with a non-default ACLProvider
> 2) I call framework.usingNamespace("/solr/zkdtsm") on the curator framework
> 3) I do some action, like starting a new SharedCount on a subnode of the namespace /testPath/ZKDTSMRoot/ZKDTSMSeqNumRoot
> Result: the tree is created, but neither /solr nor /solr/zkdtsm have ACLs, while /testPath/ZKDTSMRoot/ZKDTSMSeqNumRoot
does.  I would expect all those nodes would have ACLs because I only performed zookeeper actions
on a CuratorFramework with an ACLProvider specified.
> This seems to happen because NamespaceImpl does not save the ACLProvider, see this line:
> https://github.com/apache/curator/blob/7f2098654a26e2f593801a586ce68300f54abf15/curator-framework/src/main/java/org/apache/curator/framework/imps/NamespaceImpl.java#L47
> Then, when an action is performed on the namespace, fixForNamespace is called:
> https://github.com/apache/curator/blob/7f2098654a26e2f593801a586ce68300f54abf15/curator-framework/src/main/java/org/apache/curator/framework/imps/NamespaceImpl.java#L74
> resulting in the parents being created without an ACL.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message