[NETVIRT-1386] Better permanent solution for QosAlertGenerator which shall not modify the logging configuration at runtime Created: 26/Jul/18  Updated: 04/Oct/18  Resolved: 04/Oct/18

Status: Resolved
Project: netvirt
Component/s: None
Affects Version/s: None
Fix Version/s: Neon

Type: Improvement Priority: Medium
Reporter: Michael Vorburger Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to CONTROLLER-1845 Karaf takes 7 minutes to start Resolved

 Description   

CONTROLLER-1845 documents massive confusion, and significant total time lost by far too many busy people, until skitt found out that:

(...) this is caused by the Pax Logging configuration file having the wrong contents, so the logs aren't stored in the Karaf log file. Jamo reproduced this, and had a configuration file which only contained the lines from qosservice.cfg. So it seems that QosAlertGenerator in NetVirt is involved — it rewrites the configuration file...

and in further discussion tpantelis mentions that:

assume it's getting overwritten with log4j settings instead of log4j2 (...) seems odd for QosAlertGenerator to add fixed logging configuration in code at runtime, usually such configuration is set up on deployment if desired. I don't know the history of this but perhaps we should consider removing it.

While it may be possible to "fix up" the content of that qosservice.cfg file (log4j2 format?), I have to very strongly agree that this seems like a completely crazy approach to begin with.

https://git.opendaylight.org/gerrit/#/c/74496/ therefore removes the code that used to do runtime logging change in QosAlertGenerator to unblock CONTROLLER-1845.

This issue is to discuss if and how a better solution can be re-implemented in a future follow up change to the removal.


Generated at Wed Feb 07 20:23:56 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.