Github user Parth-Brahmbhatt commented on a diff in the pull request:
https://github.com/apache/incubator-storm/pull/190#discussion_r15417963
--- Diff: storm-core/src/clj/backtype/storm/daemon/nimbus.clj ---
@@ -1046,7 +1047,10 @@
(dissoc storm-conf
STORM-ZOOKEEPER-TOPOLOGY-AUTH-SCHEME STORM-ZOOKEEPER-TOPOLOGY-AUTH-PAYLOAD))
total-storm-conf (merge conf storm-conf)
topology (normalize-topology total-storm-conf topology)
+ nimbus-autocred-plugins
(AuthUtils/getNimbusAutoCredPlugins total-storm-conf)
--- End diff --
I have a few questions:
* Shouldn't the plugin be cleared up as soon as the scope of submit
topology is over?
* If we generate these instances at startup then it means anyone wanting to
use it will have to change the nimbus config and restart nimbus. Right now the
restart is required because renewers are designed that way. I could follow that
pattern however I think this approach is better because no restart is required
as long as all the hdfs configuration files are already in the class path.
If you like to stick to this approach I can change the code so the list of
plugins are loaded at startup and stored in nimbus data structure and their
populateCred method is invoked as part of submit topology.
We need some way of identifying who the topology submitter is. Without that
information we don't know for whom are we getting the creds. I can pass just
the topology config and I think any future implementations of the interface
would also need that. I could make the config immutable thus ensuring the user
code can not modify it, does that work ?
---
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 [email protected] or file a JIRA ticket
with INFRA.
---
