Bug 962684

Summary: [engine-backend] engine.log is flooded with "No string for UNASSIGNED type. Use default Log"
Product: Red Hat Enterprise Virtualization Manager Reporter: Elad <ebenahar>
Component: ovirt-engineAssignee: Mooli Tayer <mtayer>
Status: CLOSED CURRENTRELEASE QA Contact: Elad <ebenahar>
Severity: high Docs Contact:
Priority: high    
Version: 3.3.0CC: acanan, acathrow, bazulay, ebenahar, hateya, iheim, italkohe, jkt, lpeer, lyarwood, mtayer, pstehlik, Rhev-m-bugs, t.h.amundsen, yeylon, yzaslavs
Target Milestone: ---Keywords: Regression, Triaged, ZStream
Target Release: 3.3.0   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: infra
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 971424 (view as bug list) Environment:
Last Closed: 2013-08-25 12:58:06 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 971424    
Attachments:
Description Flags
engine logs
none
first engine log none

Description Elad 2013-05-14 09:12:43 UTC
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

Comment 2 Mooli Tayer 2013-05-28 13:33:50 UTC
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?

Comment 3 Elad 2013-05-29 07:19:33 UTC
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.

Comment 4 Yair Zaslavsky 2013-06-01 18:34:55 UTC
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.

Comment 5 Elad 2013-06-01 18:53:12 UTC
(In reply to Yair Zaslavsky from comment #4)
It was indeed upgraded from 3.1.z.

Comment 6 Yair Zaslavsky 2013-06-01 18:55:11 UTC
Elad, Can you specify which version of z-stream? (3.1.3? 3.1.4?)

Comment 9 Mooli Tayer 2013-06-05 15:21:18 UTC
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?).

Comment 10 Yair Zaslavsky 2013-06-06 11:35:53 UTC
Code is fixed upstream.
This occurs on downstream only.

Comment 14 Elad 2013-07-16 08:20:32 UTC
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.

Comment 15 Mooli Tayer 2013-07-16 10:41:12 UTC
According to comment 5, comment 8 and comment 7 it's from 3.1.4 to 3.2

Comment 16 Elad 2013-07-16 11:15:52 UTC
(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

Comment 17 Mooli Tayer 2013-07-16 11:30:17 UTC
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

Comment 18 Aharon Canan 2013-08-25 10:53:17 UTC
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...

Comment 19 Mooli Tayer 2013-08-25 12:20:21 UTC
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.

Comment 20 Aharon Canan 2013-08-25 12:58:06 UTC
Following comment #19
closing