Bug 1032661 - Add SNMP trap as notification method to to ovirt-engine-notification
Add SNMP trap as notification method to to ovirt-engine-notification
Product: oVirt
Classification: Community
Component: ovirt-engine-notificiations (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 3.4.0
Assigned To: Mooli Tayer
Petr Beňas
Depends On:
  Show dependency treegraph
Reported: 2013-11-20 09:42 EST by Barak
Modified: 2014-03-31 08:23 EDT (History)
8 users (show)

See Also:
Fixed In Version: ovirt-3.4.0-rc
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-03-31 08:23:29 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 22909 None None None Never
oVirt gerrit 24707 None None None Never

  None (edit)
Description Barak 2013-11-20 09:42:40 EST
Add the ability to send snmp traps as notification media by the ovirtnotification service
Comment 1 Alon Bar-Lev 2013-12-11 07:55:53 EST

I hear we are going forward with providing this even without having the ability to modularizing the engine.

The difference is huge - core product feature compared to external plugin, it effects installation, upgrade and support. It also introduces a new external dependency that is not part of rhel (jsnmp).

If for some reason this cannot be deferred until we have proper plugin interface for engine, I suggest to add it into notification service and not engine core, to allow killing this service functionality in future.

But these kind of feature really belongs to product customization and not product core, allowing system integration to customize the product to own needs. I suggest to defer any of these features to the time we have proper engine modularization.

Comment 2 Itamar Heim 2013-12-13 04:14:54 EST
i think this for now should be in notification service.
I think notification service should emit all AuditLog events to a log facility, allowing to customize via log4j different outputs/filters.

which makes me wonder if we can't consider log4j pluggable enough to not just have the engine do this instead of the notification service?
Comment 3 Alon Bar-Lev 2013-12-13 04:39:50 EST
(In reply to Itamar Heim from comment #2)
> which makes me wonder if we can't consider log4j pluggable enough to not
> just have the engine do this instead of the notification service?

although log4j looks promising, my experience with it is not good as application level feature, as you do not really control what it is doing.

it also lacks the ability to provide multiple configurations without overwriting single file (log4j.xml, log4j.properties), so upgrade is impossible, unless you create some mean to merge several configurations at startup.

and please remember the jboss issue with modifying log4j behavior not accepting the default java system properties.

but if it will provide a solution[1] for this issue using manual configuration, so that integrator can add this ability it will be good enough for now.

not sure why this feature is that important to modify software until we have proper infrastructure in place.

[1] http://code.google.com/p/log4j-snmp-trap-appender/
Comment 4 Alon Bar-Lev 2013-12-16 07:32:01 EST
Itamar, if we open log4j for events, and allow to load any appender will it be sufficient to close this feature?
Customer will be able to add whatever appender that suites his configuration, we do not provide anything specific to snmp.
Comment 5 Itamar Heim 2013-12-16 18:40:30 EST
I think it will be a good solution as it will allow any log4j appender, instead of us having to write different appenders.
so this would be a much more generic solution than anything we do and cover many appenders out of the box:

but question is if to resolve this specific one we need to provide the compiled snmptrap one.

barak - thoughts on this approach?
Comment 8 Sandro Bonazzola 2014-03-03 09:40:13 EST
This BZ should be fixed in oVirt 3.4.0 RC
Comment 9 Petr Beňas 2014-03-11 12:26:15 EDT
Testplan was ran on av2 build. Separate bugs for found issues were opened, so putting this bug into verified.
Comment 10 Sandro Bonazzola 2014-03-31 08:23:29 EDT
this is an automated message: moving to Closed CURRENT RELEASE since oVirt 3.4.0 has been released

Note You need to log in before you can comment on or make changes to this bug.