We switched some things around to give users more control over what is in the
worker classpath and what is not. You can set the environment variable
STORM_EXT_CLASSPATH when launching the supervisor if you want items to go on
both the worker and supervisor classpaths. You can set
STORM_EXT_CLASSPATH_DAEMON if you want them to only appear on the supervisor
classpath. storm-env.sh is a great place to put these if you want them system
wide.
- Bobby
On Wednesday, July 1, 2015 2:29 PM, Steve Davis <[email protected]>
wrote:
Has anyone tried using 0.10.0-beta1 with a custom class path (for picking up
storm.yaml in non-default locations)? I had 0.9.4 running for a while with
supervisors using a custom classpath with `/etc/storm` to pick up my config in
`/etc/storm/storm.yaml`, but it doesn’t work with 0.10.0-beta1.
It appears to me that the workers aren’t getting the classpath and/or config
from the supervisors… I know the supervisors are picking up the correct
`/etc/storm/storm.yaml` because they’re able to see the nimbus host which is
set explicitly in the yaml file. I can tell that the workers are not getting
the same config because they’re looking for the `storm.local.dir` value in the
default location (`storm-local`) rather than the location set in the custom
yaml file.
Is this the desired effect? It seems like workers should spawn with the same
config as the supervisors. In Storm UI, the “topology configuration” shows the
`/etc/storm/storm.yaml` config values, but the workers are using the one they
find in the default `<STORM_HOME>/conf`. This doesn’t seem intuitive, and is
misleading about the actual configuration that is being used.
Am I thinking about this incorrectly or doing something wrong?
Thanks,
Steve
