[
https://issues.apache.org/jira/browse/STORM-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Noll updated STORM-488:
-------------------------------
Description:
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.
was:
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
to indicate 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.
> 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 (Incubating)
> Issue Type: Bug
> Reporter: Michael Noll
> Assignee: Michael Noll
> Priority: Minor
> Labels: newbie
>
> 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)
