Red Hat Bugzilla – Full Text Bug Listing
|Summary:||[RFE] Request adding parent and grandparent resource name to SNMP Alerts|
|Product:||[Other] RHQ Project||Reporter:||dsteigne|
|Component:||Alerts||Assignee:||Larry O'Leary <loleary>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Mike Foley <mfoley>|
|Version:||3.0.1, 4.1||CC:||asantos, hrupp, ian.springer, loleary, mazz, mbenmans, mshirley, sappleto|
|Target Milestone:||---||Keywords:||NeedsTestCase, Reopened|
|Target Release:||JON 3.1.0|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-03-14 11:06:37 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description dsteigne 2011-10-07 12:20:49 EDT
Description of problem: Request ability to have the name of the JBoss instance as part of the SNMP alerts, which is in most cases the parent or the grand parent of the monitored resource. Version-Release number of selected component (if applicable): 2.4.1
Comment 1 Shaun Appleton 2011-10-21 09:20:43 EDT
Assigned to Larry base on new RFE process
Comment 2 Mohamed Hamza Ben Mansour 2011-11-02 17:38:37 EDT
Hi, As for email alert, we can include the resourceHierarchy(obtained via the ResourceManager.getResourcesAncestry) in the information sent by the SnmpTrapSender.sendSnmpTrap. The customer need is to directly identify the AS instance when alerts happen on resources such as MemoryPools or web connectors. Best Regards, Hamza
Comment 3 Mohamed Hamza Ben Mansour 2011-12-20 11:16:51 EST
Created attachment 548879 [details] Patch for the MIB change
Comment 4 Mohamed Hamza Ben Mansour 2011-12-20 11:17:26 EST
Created attachment 548880 [details] SNMP plugin change path file
Comment 5 Heiko W. Rupp 2011-12-21 12:20:38 EST
47086c0 in master
Comment 6 Charles Crouch 2012-01-16 23:04:54 EST
Pushing back to ONQA to understand more about how this was tested. SNMP alert notifications would be a good thing to automate the testing of
Comment 10 Mike Foley 2012-01-17 16:25:42 EST
1) Added keyword: "NeedsTestCase" 2) Documenting existing testcases Alert Sender SNMP Testcase: https://tcms.engineering.redhat.com/case/62045/?from_plan=2883 https://tcms.engineering.redhat.com/case/62048/?from_plan=2883 Email Alert Sender Testcases (from comment #2): https://tcms.engineering.redhat.com/case/62049/?from_plan=2883 General Alert Sender Testcases https://tcms.engineering.redhat.com/plan/2883/ ... testcases 62040 thru 62051 Sunil ... please add or update a TCMS testcase for the change in this specific BZ, and schedule a regression test of these 2 testcases: https://tcms.engineering.redhat.com/case/62045/?from_plan=2883 https://tcms.engineering.redhat.com/case/62048/?from_plan=2883 Jeeva ... please consider adding a CLI test for this ... perhaps building on the existing developer-owned Alert CLI test named testAlerts.js located in rhq/modules/cli-tests
Comment 11 Charles Crouch 2012-01-24 11:20:11 EST
Upgrades need to be tested, such that existing customers that have SNMP alerts set can continue to work unchanged.
Comment 12 John Mazzitelli 2012-02-17 10:13:26 EST
FYI: when I run the unit test that came with this patch ResourceManagerBeanTest.testResourceLineage (which, btw, has tabs in the source - a no-no), it succeeds the first time, but fails the second time and thereafter: ERROR 16-02 21:20:31,611 [org.hibernate.util.JDBCExceptionReporter] (JDBCExceptionReporter.java:logExceptions:78) -ERROR: duplicate key value violates unique constraint "rhq_agent_name_unique" Detail: Key (name)=(hamza007) already exists. Unless I'm missing something, this test needs to be fixed.
Comment 13 John Mazzitelli 2012-02-17 10:14:44 EST
moving to ASSIGNED - as far as I can tell, the unit test is broken and needs to be fixed.
Comment 14 John Mazzitelli 2012-02-17 10:22:43 EST
ips confirms this on his box too - this test doesn't clean up after itself and fails on the 2nd attempt and thereafter.
Comment 15 Ian Springer 2012-02-22 09:59:01 EST
I fixed the unit test.
Comment 17 Marc Shirley 2012-05-22 12:24:48 EDT
Changing to Verified. Steps to test: 1) Start an SNMP listener (for example, run comand 'snmptrapd -Lf /tmp/snmpd.log) 2) Create alert on a resource 3) Add condition (for example, resource goes down) 3) Add SNMP notification to alert and point to the SNMP listener 4) Save alert 5) Trigger the alert (for example, cause the resource to go down) 6) Verify alert shows in history for the resource in the JON UI 7) Verify the SNMP listener received the notification (for example, check /tmp/snmpd.log)