[jira] [Comment Edited] (STORM-617) In Storm secure mode re-deploying trident topology causes zookeeper ACL issue

["Robert Joseph Evans (JIRA)" <ji...@apache.org>]

    [ 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)