Commenting out the lines above (disabling the creation of ACLs for the Trident-state-created Zookeeper nodes) and renaming the spout works around the issue for me. I did have to do both: simply renaming the spout will fail after a restart of the topology, and ACLs will already exist for spout names that have already been created. Thanks for the workaround!
Josh On Fri, Dec 19, 2014 at 4:14 PM, Harsha <[email protected]> wrote: > Hi Josh, > This is a known issue with trident. We are working on sending > a patch. > One workaround is to re-name the spout or comment out these lines > https://github.com/apache/storm/blob/master/storm-core/src/jvm/backtype/storm/transactional/state/TransactionalState.java#L67 > https://github.com/apache/storm/blob/master/storm-core/src/jvm/storm/trident/topology/state/TransactionalState.java#L62 > > Thanks, > Harsha > On Fri, Dec 19, 2014, at 12:34 PM, Josh Bronson wrote: >> I'm looking at the secure storm branch. Specifically, I'm working off >> of the v0.9.2-incubating-security branch. I'm able to get secure Storm >> working, but a Trident topology is throwing zookeeper errors. Both are >> using standard Kafka spouts: the Trident topology, in particular is >> using >> storm.kafka.trident.OpaqueTridentKafkaSpout. Here's the error: >> >> https://gist.github.com/joshbronson/691d4b1ac5e4dd12cf59 >> >> It's looking in /transactional/test_trident_spout_name/coordinator, >> which is where the Kafka opaque spout leaves state about where it left >> off in Kafka, IIRC. >> >> The nimbus and supervisors are authenticating themselves just fine to >> the zookeeper, and are able to access nodes that have ACLs restricting >> them to [email protected]. >> >> Is there anything special needed to configure the Trident Opaque Kafka >> spout? I'm about to dig deeper into the code as well, to see if I've >> missed something. >> >> Cheers, >> Josh Bronson
