Created attachment 747568 [details] engine logs Description of problem: engine.log is flooded with: 2013-05-11 13:15:29,738 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (QuartzScheduler_Worker-23) [5e771cf1] No string for UNASSIGNED type. Use default Log [root@elad-rhevm31 ~]# less /var/log/ovirt-engine/engine.log.1-20130514_031701_2043.xz | grep UNASSIGNED | wc -l 1747 Version-Release number of selected component (if applicable): rhevm-3.2.0-10.25.beta3.el6ev.noarch Additional info: see logs attached
I've built the relevant tag ( rhev-3.2.0_beta3_sf16 ) and I cannot see the aforementioned string. Could you please provide additional Info? What operation causes the string to be printed?
Created attachment 754206 [details] first engine log it appears ever since the upgrade from 3.1 to 3.2. attached the first engine.log which it appeared.
Muli, I saw this in another environment. May also be due to upgrade. Perhaps this has to due to elimination of status UNASSIGNED from 3.1 to 3.2, and now 3.2 does not know this enum and how to translate it? Worth checking code of 3.1.z as well. Please communicate Elad and ask him from which 3.1 (probably a z-stream) he upgraded, and then we can compare the code. Anyway, this will only give us the root cause to the problem. We should decide how to handle these situations - let's discuss some options ASAP.
(In reply to Yair Zaslavsky from comment #4) It was indeed upgraded from 3.1.z.
Elad, Can you specify which version of z-stream? (3.1.3? 3.1.4?)
The cause of this error: There is a mechanism in the audit log that prevents multiple messages under the same logType ( e.g command ) from being printed inside a certain time frame. It seems that since commit 5aedb99 the logic was changed to write "No string for X Type. Use default log" when that mechanism should actually just prevent logging. That string should actually be printed when a message for a logType is not found in AuditLogMessages.properties. I see that it has already been fixed upstream. I created a patch and will submit it tomorrow under the relevant stream/s (3.1.4?).
Code is fixed upstream. This occurs on downstream only.
Hi Mooli, On what version do I suppose to reproduce this bug? upgrade from 3.2 to 3.3? because currently, this upgrade is not possible.
According to comment 5, comment 8 and comment 7 it's from 3.1.4 to 3.2
(In reply to Mooli Tayer from comment #15) > According to comment 5, comment 8 and comment 7 it's from 3.1.4 to 3.2 Yes, the bug had been opened about upgrading from 3.1.4 to 3.2. My question is if it's still relevant to check this upgrade (from 3.1.4 to 3.2) or to check from 3.2 to 3.3
I see. I would say a 3.1.4->3.2 upgrade is a better check. The reason is that this bug isn't on the upgrade process itself, but on logging of events that should have been surpassed. We know that people met these events on a 3.1.4->3.2 upgrade but we can't assume the same will happen for a 3.2->3.3 upgrade
Mooli, on what 3.3 version can I find the fix? and I am still missing something here - if the fix is target here to 3.3 and the verification is upgrade from 3.1 to 3.2, I don't get how the 3.3 is relevant, we are not using 3.3 while verifying at all...
Hi Aharon, This bug happens and was fixed on 3.2.1. According to what I saw, this bug never existed on 3.3 this is the z-stream clone of this bug: bug 971424 IMO This bug should be closed as "current release" as it never happened on 3.3.
Following comment #19 closing