Bug 962684 - [engine-backend] engine.log is flooded with "No string for UNASSIGNED type. Use default Log"
[engine-backend] engine.log is flooded with "No string for UNASSIGNED type. U...
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
x86_64 Unspecified
high Severity high
: ---
: 3.3.0
Assigned To: Mooli Tayer
: Regression, Triaged, ZStream
Depends On:
Blocks: 971424
  Show dependency treegraph
Reported: 2013-05-14 05:12 EDT by Elad
Modified: 2016-02-10 14:10 EST (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 971424 (view as bug list)
Last Closed: 2013-08-25 08:58:06 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
engine logs (835.83 KB, application/x-gzip)
2013-05-14 05:12 EDT, Elad
no flags Details
first engine log (432.39 KB, application/x-gzip)
2013-05-29 03:19 EDT, Elad
no flags Details

  None (edit)
Description Elad 2013-05-14 05:12:43 EDT
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

Version-Release number of selected component (if applicable):

Additional info: see logs attached
Comment 2 Mooli Tayer 2013-05-28 09:33:50 EDT
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 03:19:33 EDT
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 14:34:55 EDT
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 14:53:12 EDT
(In reply to Yair Zaslavsky from comment #4)
It was indeed upgraded from 3.1.z.
Comment 6 Yair Zaslavsky 2013-06-01 14:55:11 EDT
Elad, Can you specify which version of z-stream? (3.1.3? 3.1.4?)
Comment 9 Mooli Tayer 2013-06-05 11:21:18 EDT
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 07:35:53 EDT
Code is fixed upstream.
This occurs on downstream only.
Comment 14 Elad 2013-07-16 04:20:32 EDT
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 06:41:12 EDT
According to comment 5, comment 8 and comment 7 it's from 3.1.4 to 3.2
Comment 16 Elad 2013-07-16 07:15:52 EDT
(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 07:30:17 EDT
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 06:53:17 EDT

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 08:20:21 EDT
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 08:58:06 EDT
Following comment #19

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