Bug 733241

Summary: 'qpid-config queues <queue_name>' should return proper error code
Product: Red Hat Enterprise MRG Reporter: Stanislav Graf <sgraf>
Component: qpid-toolsAssignee: Nuno Santos <nsantos>
Status: CLOSED ERRATA QA Contact: Petr Matousek <pematous>
Severity: low Docs Contact:
Priority: low    
Version: 2.0CC: aortega, jross, pematous, tross
Target Milestone: 2.1.2   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: qpid-tools-0.14-1.el5 Doc Type: Bug Fix
Doc Text:
Cause When listing queues using 'qpid-config queues <queue_name>', qpid-config always returns 0, regardless of whether the queue exists. Similar behavior for listing exchanges. Consequence Scripts that use the return code of qpid-config to detect the presence of a queue or exchange will not work. Fix The fix makes qpid-config return the correct/expected return code, based on the existence of the named queue. The fix also corrects similar behavior for listing exchanges. Result Scripts can now make use of the return code from qpid-config when listing named queues or exchanges.
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-30 17:52:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 783492    

Description Stanislav Graf 2011-08-25 09:30:52 UTC
Description of problem:

When listing queues using 'qpid-config queues <queue_name>', qpid-config returns always '0'
(regardless whether queue exists)

[root ~]# qpid-config add queue queue_test
[root ~]# qpid-config queues queue_test
Queue Name  Attributes
===================================
queue_test 
[root ~]# echo $?
0
[root ~]# qpid-config del queue queue_test
[root ~]# qpid-config queues queue_test
Queue Name  Attributes
===================================
[root ~]# echo $?
0

'qpid-config queues' behavior is fine, but 'qpid-config queues <queue_name>' should behave more like grep.

Version-Release number of selected component (if applicable):
qpid-tools-0.10-5.el6.noarch
qpid-tools-0.7.946106-12.el5


How reproducible:
100%

Steps to Reproduce:
1. qpid-config add queue queue_test
2. qpid-config queues queue_test
3. echo $?
4. qpid-config del queue queue_test
5. qpid-config queues queue_test
6. echo $?

Actual results:
Queue doesn't exist -> return code '0'

Expected results:
Queue doesn't exist -> return code '1'
("grep-like" behavior)

Additional info:

Comment 1 Nuno Santos 2011-09-08 20:30:09 UTC
Fixed at svn rev 1166888:
https://svn.apache.org/viewvc/qpid/trunk/qpid/tools/src/py/qpid-config?view=diff&r1=1166887&r2=1166888&pathrev=1166888

Btw, I also fixed the same behavior for listing exchanges, in addition to queues.

Comment 4 Petr Matousek 2011-12-21 10:19:51 UTC
This issue has been fixed.

Verified on RHEL5.7 and RHEL6.2, architectures: x86_64, i686 

packages installed:
qpid-cpp-mrg-0.14-3.el5
qpid-cpp-0.14-1.el6

-> VERIFIED

Comment 5 Petr Matousek 2011-12-21 10:22:05 UTC
correction:

packages installed:
qpid-tools-0.14-1.el5
qpid-tools-0.14-1.el6

-> VERIFIED

Comment 6 Nuno Santos 2012-03-08 15:37:51 UTC
    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:
Cause
    When listing queues using 'qpid-config queues <queue_name>', qpid-config always 
returns 0, regardless of whether the queue exists. Similar behavior for listing exchanges.
Consequence
    Scripts that use the return code of qpid-config to detect the presence of a queue or exchange will not work.
Fix
    The fix makes qpid-config return the correct/expected return code, based on the existence of the named queue. The fix also corrects similar behavior for listing exchanges.
Result
   Scripts can now make use of the return code from qpid-config when listing named queues or exchanges.

Comment 7 errata-xmlrpc 2012-04-30 17:52:13 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2012-0529.html