Github user HeartSaVioR commented on the issue: https://github.com/apache/storm/pull/2208 OK now I'm seeing how it works... From topology side it's always set to "digest" from Storm Submitter, so it is not effectively configurable from topology level. From Daemon (Nimbus, Supervisor, etc) side, it **determines** whether the cluster is using ZK auth via STORM_ZOOKEEPER_AUTH_SCHEME (cluster-wise ZK auth). Especially, Nimbus just **removes** STORM_ZOOKEEPER_TOPOLOGY_AUTH_SCHEME (topology-wise ZK auth) from topology config map when topology is submitted but STORM_ZOOKEEPER_AUTH_SCHEME is not set. The tricky part is a ZookeeperAuthInfo class. If STORM_ZOOKEEPER_TOPOLOGY_AUTH_SCHEME is set to cluster configuration, ZookeeperAuthInfo uses this. That means, if ZookeeperAuthInfo class is used from Daemon side, topology-wise configuration will be used. (I feel this behavior could be misleading.) So it shouldn't be set to "digest" with no auth. Long story in short, javadoc comment is effectively right even though it is really tricky. I'm not an expert of ZK auth and wondering why cluster wise configuration and topology wise configuration co-exist, given that it connects to same ZK. Could someone knowing about ZK auth explain this?
--- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---