Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 954003

Summary:	Event Viewer Must Convey More Meta-Data when there are faults.
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Keith Robertson <kroberts>
Component:	RFEs	Assignee:	Keith Robertson <kroberts>
Status:	CLOSED DUPLICATE	QA Contact:	Yaniv Kaul <ykaul>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	3.2.0	CC:	abaron, acathrow, dyasny, iheim, italkohe, jkt, jmoran, jwest, lpeer, lyarwood, nigjones, sgrinber, sshumake, vszocs
Target Milestone:	---	Keywords:	FutureFeature, Triaged
Target Release:	3.3.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	ux
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-06-17 20:10:43 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	894399

Description Keith Robertson 2013-04-19 20:15:00 UTC

1. Proposed title of this feature request
Event Viewer Must Convey More Meta-Data when there are faults.

2. Who is the customer behind the request?
Red Hat 

3. What is the nature and description of the request?
Currently, the amount of information that is conveyed in a fault detected by the event viewer is very terse.  We need more information such that we can provide diagnostic services.  It would be particularly helpful if the event conveyed an actual exception (e.g. java.lang.Exception).

4. Why does the customer need this? (List the business requirements here)
Diagnostic services.

5. How would the customer like to achieve this? (List the functional requirements here)
More data please a flow ID is not enough.  We either need message IDs or a stacktrace.

6. List any affected packages or components.
The Red Hat Support Plug-in for RHEV is adversely affected by the fact that the event viewer is not plug-able.

7. Would the customer be able to assist in testing this functionality if implemented?
Yes.

Comment 1 Vojtech Szocs 2013-05-09 16:12:58 UTC

The "Events" main tab renders org.ovirt.engine.core.common.businessentities.AuditLog business entity data, which can be passed to UI plugins.

AuditLog contains correlationId that could be used to correlate given event with backend logs. AuditLog does not contain any sort of exception /stacktrace/ information.

If we need possible stacktrace information associated with given event, we must do "correlationId --> stacktrace" lookup in one way or another. The question is, who should be responsible for this, i.e. plugin vs. WebAdmin/GUI infrastructure.

Comment 2 Spenser Shumaker 2013-05-13 17:39:18 UTC

We don't mind being responsible for this work.  Although, if we are responsible, can you tell us where/how we would be able to use the correlation id to look up the stack-trace info?  Is it in the database?

Comment 3 Vojtech Szocs 2013-05-15 15:37:23 UTC

Hi Spenser, here are some details and examples based on my observation of backend code and runtime behavior:

AuditLog's correlationId attribute is set only when executing business commands (CommandBase extends AuditLogableBase) - in other words, AuditLog.correlationId != null only when the given AuditLog describes a logical business operation (command) triggered by Frontend and executed by Backend.

I noticed that not all AuditLog entries describing command execution have correlationId != null, not sure why, though. For example, in engine.log:

Following line represents AuditLog describing admin user logging into WebAdmin (no correlationId present):
... [org.ovirt.engine.core.bll.LoginAdminUserCommand] (http--0.0.0.0-8700-1) Running command: LoginAdminUserCommand internal: false.

Following line represents AuditLog describing creation of new Data Center from WebAdmin (correlationId is present -> 6a586baf):
... [org.ovirt.engine.core.bll.storage.AddEmptyStoragePoolCommand] (http--0.0.0.0-8700-1) [6a586baf] Running command: AddEmptyStoragePoolCommand internal: false. Entities affected :  ID: aaa00000-0000-0000-0000-123456789aaa Type: System

Following line represents AuditLog describing deletion of existing Data Center from WebAdmin (correlationId is present -> 59d5a973):
... [org.ovirt.engine.core.bll.storage.RemoveStoragePoolCommand] (pool-8-thread-49) [59d5a973] Running command: RemoveStoragePoolCommand internal: false. Entities affected :  ID: 9c6ca25e-68cc-42cb-8ed2-91e14d91021a Type: StoragePool

So if correlationId is available (not null), you can parse $JBOSS_HOME/standalone/log/engine/engine.log - looking for "[<correlationId>]" and extracting logs that immediately follow the matching line, including any exception/stacktrace information. (AFAIK this is the only way to lookup possible exception/stacktrace information based on AuditLog correlationId.)

Comment 4 Keith Robertson 2013-06-17 20:10:43 UTC

I'm going to close this BZ.  I think that this shd be fixed by a combination of BZ966198 and BZ966192.  If necessary will revisit after those are completed.

*** This bug has been marked as a duplicate of bug 966198 ***