Description of problem: Sosreport plugin to collect the "M" part in MRG Plugin will collect the following from the Broker 1. check whether qpidd packages are installed and will collect the default configuration file 2. Will collect the following command outputs from the broker and will be saved under sos_command/broker/ in the sosreport qpid-stat [-b/-e/-q] Version-Release number of selected component (if applicable): sos-1.7-9.43 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Does not collect Messaging information Expected results: Collect the default configuration commands Additional info:
Created attachment 386209 [details] qpidd.py.patch
looks to already be a mrg messaging plugin... that plugin (mrgmessg.py) already grabs: self.addCopySpec("/etc/qpidd.conf") self.addCopySpec("/etc/sasl2/qpidd.conf") self.addCopySpec("/var/rhm") then this patch (qpidd.py.patch) grabs: self.addCopySpec("/etc/qpidd.conf") self.collectExtOutput("/usr/bin/qpid-stat -q") self.collectExtOutput("/usr/bin/qpid-stat -e") self.collectExtOutput("/usr/bin/qpid-stat -b") do you also want to grab these ? self.addCopySpec("/var/lib/qpid/syslog") self.addCopySpec("/var/lib/qpid/systemId") self.collectExtOutput("/usr/bin/qpid-config") self.collectExtOutput("/usr/bin/qpid-config -b exchanges") self.collectExtOutput("/usr/bin/qpid-config -b queues") self.collectExtOutput("/usr/bin/qpid-stat -c")
The syslog might certainly be useful, the systemId in general less so. Most of the info in those extra qpid-config commands would already be obtainable from the qpid-stats in qpidd.py.patch, they do add details of any extra configuration properties and the top-level summary of counts could be convenient as a snapshot so there is probably no harm in adding them in. Note that those commands would error if the service wasn't running.
should we also grab the jinf meta-data files that describe each durable queue ? is there some other way of finding out the command used to create a durable queue while the broker is not running ?
if certain problems are client-language or otherwise client specific, then we need to collect data about the client via sosreport: client version client os client language
Created attachment 394339 [details] updated patch
Created attachment 398090 [details] patch
Jeremy, Please verify attached patch satisfies requirements for running the commands in setup method. Thanks, Adam
Created attachment 398096 [details] patch
Hi Jeremy, Could you test this attached patch? I re-ran it through pylint and no errors are coming up so hopefully it will load. Thanks, Adam
Patch tested on mrg system; seems to work.
Created attachment 398544 [details] patch
Jeremy/Andrew, Please have a look at latest attachment to see if the new additions are appropriate. Thanks, Adam
Looks good. --jer
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-2010-0201.html