Bug 1032661

Hello,

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.

Thanks,
Alon

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?

(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/

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.

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:
http://logging.apache.org/log4j/2.x/manual/appenders.html

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

barak - thoughts on this approach?

This BZ should be fixed in oVirt 3.4.0 RC

Testplan was ran on av2 build. Separate bugs for found issues were opened, so putting this bug into verified.

this is an automated message: moving to Closed CURRENT RELEASE since oVirt 3.4.0 has been released