rescue DEFAULT_STORM_CONF_FILE so we can use redstorm in envs with no HOME

[ismith]

If our local environment doesn't have a HOME, we might still specify conf file via -Dstorm.conf.file=foo; but the default still requires that ENV['HOME'] exist. This patch rescues the resulting error so we don't depend on ENV['HOME'].

[coveralls]

Coverage remained the same when pulling fc664f801dda543d0075d10edd6fea4eaa76654f on lookout:storm_file into af79df05facfa952e71521599cae0efafb3bc9d9 on colinsurprenant:master.

[colinsurprenant]

I am surprised this actually works when submitting to cluster: it will be used at https://github.com/colinsurprenant/redstorm/blob/master/lib/red_storm/application.rb#L46 and passed to the launch task and should fail here https://github.com/colinsurprenant/redstorm/blob/master/lib/tasks/red_storm.rake#L29 ?!?

[ismith]

We've been using this successfully in our fork; it shouldn't be using DEFAULT_STORM_CONF_FILE, because we've specified a -Dstorm.conf.file

[colinsurprenant]

are you launching the cluster using redstorm cluster ? if you do it is set here https://github.com/colinsurprenant/redstorm/blob/master/lib/red_storm/application.rb#L16 so I am wondering how this can work for you!?

[ismith]

No, we're launching the jar using storm. storm jar <jar> -Dstorm.conf.file=config/storm.yaml -Djruby.compat.version=RUBY1_9 redstorm.TopologyLauncher cluster <topo_path>

[colinsurprenant]

ok, that explains it... so this patch does prevent the crash but will not work if the redstorm cluster command is used. we should think about the best way to have the redstorm cluster command more flexible, using env variables so that the parameters can be overwritten?

[ismith]

I'm going to close this as inactive, two years later; if someone wants to resurrect the code, feel free.