Description of problem: In some cases when there is bad input used wallaby utility returns wrong code (0) E.g. 'wallaby -arg' 'wallaby make-snapshot' 'wallaby dump -arg' ... Version-Release number of selected component (if applicable): wallaby-utils-0.9.18-2 How reproducible: 100% Steps to Reproduce: 1. run wallaby utility with wrong option 'wallaby -arg' 2. see return code 'echo $?' Actual results: wallaby utility returns 0 Expected results: wallaby should return other number than 0 Additional info:
Fixed in master; packaged in the next version post-0.9.22.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: C: Some error conditions may cause the wallaby shell to exit with a 0 status. C: This is confusing, since 0 exit statuses typically indicate success. F: These cases are handled generally as a result of internal improvements to the wallaby shell. R: The wallaby shell will now exit with an appropriate (nonzero) exit status in error cases.
The Behaviour was fixed for the listed commands, but there are still lot of cases with incorrect return value. The issue should be solved more in general. below are listed some examples: 1.) wallaby make-snapshot command was changed to raise an error message and return non-zero error code when no argument is supplied. The behaviour should be unified for all commands requiring an argument: # correct [root ~]# wallaby make-snapshot fatal: you must specify exactly one snapshot name [root ~]# echo $? 1 # incorrect [root ~]# wallaby add-feature [root ~]# echo $? 0 [root ~]# wallaby add-node [root ~]# echo $? 0 ... 2.) Listing wallaby snapshot should end with success even if there are no snapshots [root ~]# wallaby list-snapshots Console Connection Established... [root ~]# echo $? 1 3.) Getting help for command should end with success: [root ~]# wallaby help load Usage: wallaby load SNAPFILE Loads a wallaby snapshot from SNAPFILE.. -h, --help displays this message -a, --activate attempt to activate config after loading -q, --quiet do not provide progress on load feedback -v, --verbose provide more progress on load feedback [root ~]# echo $? 1 4.) Showing, modifying and removing not existing features or params should exit with non-zero exit code [root ~]# wallaby modify-feature nonexist Modifying the following feature: nonexist with {} Console Connection Established... warning: couldn't find feature nonexist [root ~]# echo $? 0 [root ~]# wallaby show-param nonexist Console Connection Established... warning: couldn't find param nonexist [root ~]# echo $? 0 [root ~]# wallaby remove-param nonexist Removing the following param: nonexist Console Connection Established... [root ~]# echo $? 0 5.) Explaining not existing node should exit with non-zero exit code. [root ~]# wallaby explain nonexist Console Connection Established... ### Explaining the configuration for notexist # WALLABY_CONFIG_VERSION is set automatically WALLABY_CONFIG_VERSION = 0 [root ~]# echo $? 0 6.) Displaying not existing node should exit with non-zero exit code, moreover error message should appear and no nodes should not be displayed. show node : [root ~]# wallaby show-node nonexist Console Connection Established... notexist name: "notexist" provisioned: false last_checkin: 0 last_updated_version: 0 memberships: [] [root ~]# echo $? 0 Should I raise separate bugzilla for the issue no.6? Version-Release number of selected component: wallaby-utils-0.10.0-2.el5 ASSIGNED
Issue number 6 is due to the show-node command using the getNode API call, which creates a node if it doesn't exist. Nice catch!
I've marked this MODI again and have split the new issues Petr raised off into separate bugs cloned from this one.
Version: wallaby-0.10.4-2 There are still some commands which ends with incorrect code: 1.) Following command shouldn't print invalid option and should end with success - 0 # wallaby feature-import --help invalid option: --help Usage: wallaby feature-import [options] FILE Imports a wallaby feature from a specially-formatted configuration file. -h, --help displays this message -n, --name NAME name for given feature (overrides one specified in the file) # echo $? 1 2.) Wallaby command with invalid argument should exit with non-zero code # wallaby -arg invalid argument: -arg Usage: wallaby [options] command [command-args] Use "wallaby help commands" for a list of commands -h, --help shows this message -H, --host HOSTNAME qpid broker host (default localhost) -p, --port NUM qpid broker port (default 5672) -U, --user NAME qpid username -P, --password PASS qpid password -M, --auth-mechanism PASS authentication mechanism (ANONYMOUS, PLAIN, GSSAPI) # echo $? 0 >>> ASSIGNED
Comment 8 is now bug 673520
Except from comment 8, which will be corrected later (new bug 673520 was created for that), it seems OK. Tested with (version): wallaby-0.10.4-2 Tested on: RHEL5 i386,x86_64 - passed >>> VERIFIED
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,4 +1 @@ -C: Some error conditions may cause the wallaby shell to exit with a 0 status. +In certain cases, error conditions could cause the 'wallaby' shell to exit with a status code 0 (which normally indicates a successful end of an operation) even though the operation did not complete successfully. As a result of general improvements to the 'wallaby' shell, in any error cases, the 'wallaby' shell exits with an appropriate (non-zero) status code.-C: This is confusing, since 0 exit statuses typically indicate success. -F: These cases are handled generally as a result of internal improvements to the wallaby shell. -R: The wallaby shell will now exit with an appropriate (nonzero) exit status in error cases.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0217.html