[jira] [Resolved] (STORM-488) storm CLI tool reports zero exit code on error scenario

["P. Taylor Goetz (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/STORM-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

P. Taylor Goetz resolved STORM-488.
-----------------------------------
       Resolution: Fixed
    Fix Version/s: 0.9.3

> storm CLI tool reports zero exit code on error scenario
> -------------------------------------------------------
>
>                 Key: STORM-488
>                 URL: https://issues.apache.org/jira/browse/STORM-488
>             Project: Apache Storm
>          Issue Type: Bug
>    Affects Versions: 0.9.3
>            Reporter: Michael Noll
>            Assignee: Michael Noll
>            Priority: Minor
>              Labels: newbie
>             Fix For: 0.9.3
>
>
> The {{storm}} CLI tool incorrectly reports a zero exit code ("success") when it should report a non-zero exit code ("error") under the following condition.
> h3. How to reproduce
> {code}
> $STORM_HOME/bin/storm unsupportedCommand
> {code}
> h3. Actual result (incorrect)
> The command above prints the usage help of the {{storm}} CLI tool, which is ok.  However, the exit code is 0, indicating success.
> {code}
> $ /opt/storm/bin/storm unsupportedCommand
> Unknown command: [storm unsupportedCommand]
> Commands:
> 	activate
> 	classpath
> 	deactivate
> 	dev-zookeeper
> 	drpc
> 	help
> 	jar
> 	kill
> 	list
> 	localconfvalue
> 	logviewer
> 	nimbus
> 	rebalance
> 	remoteconfvalue
> 	repl
> 	shell
> 	supervisor
> 	ui
> 	version
> Help:
> 	help
> 	help <command>
> Documentation for the storm client can be found at http://storm.incubator.apache.org/documentation/Command-line-client.html
> Configs can be overridden using one or more -c flags, e.g. "storm list -c nimbus.host=nimbus.mycompany.com"
> $ echo $?
> 0    << zero exit code, should be non-zero
> {code}
> The problem of the current behavior is that automated deployment tools such as Puppet or Ansible fail to work correctly because they assume a zero exit code indicates success.
> As a concrete example, imagine you mistype the command to submit a topology jar file to a Storm cluster:
> {code}
> # Doh, forgot to put the "jar" command between `storm` and `mytopology.jar`!
> $ /opt/storm/bin/storm mytopology.jar my.Class
> # Correct would be:
> #    $ /opt/storm/bin/storm jar mytopology.jar my.Class
> {code}
> In this example, even though the user mistyped the submit command in e.g. an Ansible script, the script would not be able to tell -- the storm CLI tool incorrectly reports that the (wrong) command completed successfully.
> h3. Expected result (correct)
> Running the storm CLI tool with an unsupported command should return a non-zero exit code to clearly indicate an error condition.
> *The only remaining question would be:  What would be the actual, non-zero exit code?*
> For example, running the storm CLI tool without any argument returns an exit code of 255:
> {code}
> $ /opt/storm/bin/storm
> ...snip...
> $ echo $?
> 255
> {code}
> Unfortunately, my understanding is that we haven't defined the semantics of non-zero exit codes.  Their values are IMHO not deliberately chosen.
> For instance, if you run the "storm jar" command these are (some of) its possible exit codes:
> {code}
> 0: success
> 1:
>   - topology of same name already exists
>     `Exception in thread "main" java.lang.RuntimeException: Topology with name `mytopology` already exists on cluster`
>   - class cannot be found (`storm jar storm-starter.jar storm.starter.IDoNotExistAtAll`)
>     `Exception in thread "main" java.lang.NoClassDefFoundError: storm/starter/IDoNotExistAtAll`  (<<< logged to STDERR)
>   - incorrect use of command line, e.g. wrong number of command line arguments
> {code}
> As you can see, we return an exit code of 1 for a variety of error conditions.  On the positive side, at least it's clear that there was an error.  On the negative side, we cannot tell different error conditions apart because the same exit code is used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)