Bug 1479693 - AuditLogDirector does not log messages if transactional command fails
AuditLogDirector does not log messages if transactional command fails
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
4.1.4
Unspecified Unspecified
unspecified Severity high
: ovirt-4.1.6
: ---
Assigned To: Miroslava Voglova
Jiri Belka
: CodeChange, ZStream
Depends On: 1432127
Blocks: 1418641
  Show dependency treegraph
 
Reported: 2017-08-09 04:14 EDT by Oved Ourfali
Modified: 2017-09-19 03:18 EDT (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1432127
Environment:
Last Closed: 2017-09-19 03:18:50 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 77605 None None None 2017-08-09 04:14 EDT
oVirt gerrit 80958 ovirt-engine-4.1 MERGED core: start new transaction for AuditLogDirector 2017-08-23 09:45 EDT

  None (edit)
Description Oved Ourfali 2017-08-09 04:14:15 EDT
+++ This bug was initially created as a clone of Bug #1432127 +++

Description of problem:
If some command fails (e.g. UpdateClusterCommand) than the transactions are rolled back. The AuditLogDirector is running in the same transaction so also the logs logged using audit log are rolled back.

Steps to Reproduce:
1. use any command which is not managing it's own transactions (e.g. does not have the @NonTransactiveCommandAttribute)
2. log something using AuditLogDirector
3. fail the command using setSucceeded(false);

Actual results:
all the transactions are rolled back removing also the audit log messages

Expected results:
the audit log is survives the command failure

--- Additional comment from Martin Perina on 2017-03-16 05:18:45 EDT ---

Reducing severity as this behaviour is present in the code at least since 3.5 (maybe from beginning)

--- Additional comment from Tomas Jelinek on 2017-08-09 04:05:01 EDT ---

Any chance to get this to some z-stream? It is really important for the cluster upgrade flows since this is the place we would like to report the reasons for failed update. Without this patch the users need to dig into logs to understand what happened.

--- Additional comment from Oved Ourfali on 2017-08-09 04:06:33 EDT ---

Makes sense to me.
I'll clone it.

--- Additional comment from Tomas Jelinek on 2017-08-09 04:09:30 EDT ---
Comment 1 Red Hat Bugzilla Rules Engine 2017-08-09 04:14:26 EDT
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Comment 4 rhev-integ 2017-08-24 14:13:10 EDT
WARN: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Found non-acked flags: '{'rhevm-4.1.z': '?'}', ]

For more info please contact: rhv-devops@redhat.comINFO: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Found non-acked flags: '{'rhevm-4.1.z': '?'}', ]

For more info please contact: rhv-devops@redhat.com
Comment 5 Jiri Belka 2017-09-04 12:40:14 EDT
ok, ovirt-engine-backend-4.1.6.1-0.1.el7.noarch

audit_log still works:

 2017-09-04 18:29:51.032+02 | User admin@internal-authz is connected to VM jbelka-ngntest1.
 2017-09-04 18:29:30.882+02 | User admin@internal-authz initiated console session for VM jbelka-ngntest1
Comment 7 errata-xmlrpc 2017-09-19 03:18:50 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:2749

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