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.
---
