Yeah, I had originally added that feature a while back in https://issues.apache.org/jira/browse/METRON-356. But strictly speaking I think it should be able to be specified at the topology level per the Storm docs, https://github.com/apache/storm/blob/master/conf/defaults.yaml#L224
On Tue, Apr 25, 2017 at 3:11 PM, David Lyle <[email protected]> wrote: > I think you have one more restart than is strictly required but I get your > point. IIRC, when I did the original implementation there was a bit of a > wrinkle getting the right configs on the right classpath so I punted in > favor of topology.classpath. > > If you've got a more efficient way, I'm all for it. > > -D... > > > On Tue, Apr 25, 2017 at 4:55 PM, Michael Miklavcic < > [email protected]> wrote: > > > We currently define topology.classpath at the global level for Storm. The > > reason for this feature was to enable setting the classpath to include > > things like hbase-site and core-site without modifying the topology jar > > files on the cluster. That made things simpler, but this also has the > > consequence that Metron's installation process via Ambari looks something > > like this: > > > > 1. Install Metron > > 2. Start Metron - part of install process > > 3. Restart Storm - bc of the new property that has been added that > > needs to be distributed > > 4. Restart Metron - the topologies won't get the new classpath > otherwise > > > > We're in effect restarting Metron a couple times, which can take some > time. > > > > A possible alternative here is to set the classpath on the individual > > topologies. By doing so, we remove the need to restart Storm and Metron > > during the install. The down side is that this requires us to duplicate > > this setting for every flux file or topology, including newly-added > > topologies. What do folks think about which would be better? > > > > Best, > > Mike > > >
