[
https://issues.apache.org/jira/browse/STORM-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14375901#comment-14375901
]
Robert Joseph Evans edited comment on STORM-617 at 3/23/15 1:53 PM:
--------------------------------------------------------------------
The way to work around this, and what we have been doing is having trident
topologies override the randomly generated secret with their own secret that
persists across relaunches of a topology.
{code}storm jar ... -c
'storm.zookeeper.auth.payload="user-part:password-part"'{code}
I know it is far from ideal, but it works. In the ideal world nimbus would
recognize the two trident topologies were related and could then update the
ACLs accordingly, if they were owned by an appropriate user. The issue is that
nimbus is not actually aware of the transactional state in any way. Trident is
really a library sitting on top of core storm, and the transactional state
could even be updated to point to a different ZK instance that nimbus is not
aware of. These are the reasons why we went with the quick and dirty solution.
I thought I had updated the documentation to include this, but looking at it
now I see I didn't. I'm really sorry about that.
was (Author: revans2):
The way to work around this, and what we have been doing is having trident
topologies override the randomly generated secret with their own secret that
persists across relaunches of a topology.
```storm jar ... -c 'storm.zookeeper.auth.payload="user-part:password-part"'```
I know it is far from ideal, but it works. In the ideal world nimbus would
recognize the two trident topologies were related and could then update the
ACLs accordingly, if they were owned by an appropriate user. The issue is that
nimbus is not actually aware of the transactional state in any way. Trident is
really a library sitting on top of core storm, and the transactional state
could even be updated to point to a different ZK instance that nimbus is not
aware of. These are the reasons why we went with the quick and dirty solution.
I thought I had updated the documentation to include this, but looking at it
now I see I didn't. I'm really sorry about that.
> In Storm secure mode re-deploying trident topology causes zookeeper ACL issue
> -----------------------------------------------------------------------------
>
> Key: STORM-617
> URL: https://issues.apache.org/jira/browse/STORM-617
> Project: Apache Storm
> Issue Type: Bug
> Affects Versions: 0.10.0
> Reporter: Sriharsha Chintalapani
> Assignee: Sriharsha Chintalapani
> Priority: Blocker
>
> This issue is caused by this line
> https://github.com/apache/storm/blob/master/storm-core/src/jvm/backtype/storm/transactional/state/TransactionalState.java#L67
> If the storm cluster nimbus is running with a kerberos principal named
> "nimbus"
> and supervisors are running with principal "storm" . Storm puts the acl on
> trident spout using principal "nimbus" and this won't be able to accessed or
> modified by supervisor since they are logging into zookeeper as user "storm".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
