Bug 1432127

Summary:	AuditLogDirector does not log messages if transactional command fails
Product:	[oVirt] ovirt-engine	Reporter:	Tomas Jelinek <tjelinek>
Component:	BLL.Infra	Assignee:	Miroslava Voglova <mvoglova>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Jiri Belka <jbelka>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	---	CC:	bugs, dron, lsvaty, mperina, mvoglova, oourfali
Target Milestone:	ovirt-4.2.0	Keywords:	CodeChange
Target Release:	4.2.0	Flags:	rule-engine: ovirt-4.2+ jbelka: testing_plan_complete-
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	No Doc Update
Doc Text:	undefined	Story Points:	---
Clone Of:
Clones:	1479693 (view as bug list)		Environment:
Last Closed:	2017-12-20 10:54:31 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:	1418641, 1479693

Description Tomas Jelinek 2017-03-14 15:02:00 UTC

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

Comment 1 Martin Perina 2017-03-16 09:18:45 UTC

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

Comment 2 Tomas Jelinek 2017-08-09 08:05:01 UTC

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.

Comment 3 Oved Ourfali 2017-08-09 08:06:33 UTC

Makes sense to me.
I'll clone it.

Comment 4 Tomas Jelinek 2017-08-09 08:09:30 UTC

*** Bug 1478879 has been marked as a duplicate of this bug. ***

Comment 7 Jiri Belka 2017-10-06 16:37:35 UTC

not sure if it works as it should:

- i have 4.1 cluster with vm
- created UserDefinedVMProperties for 4.1 cluster
- assigned this property to vm in 4.1 cluster
- i make UserDefinedVMProperties empty
- vm in 4.1 cluster still had the property in its settings (check in DB)
- increased cluster to 4.2

~~~
Error while executing action: Update of cluster compatibility version failed because there are VMs/Templates [jbelka-test1] with incorrect configuration. To fix the issue, please go to each of them, edit and press OK. If the save does not pass, fix the dialog validation.
~~~

- edit vm, save
- increase cluster to 4.2

<same error as above>

- edit vm, change custom compat level to 4.2
- the property disappeared in db for the vm
- increased successfully cluster level

so, is the error above enough meaningful for users? i don't think so.

Comment 9 Miroslava Voglova 2017-10-09 07:18:42 UTC

Actually, this bug is about not logging at all due to transaction that was rolled back. If the message is not enough meaningful, I would suggest opening new bug.

(In reply to Jiri Belka from comment #7)
> not sure if it works as it should:
> 
> - i have 4.1 cluster with vm
> - created UserDefinedVMProperties for 4.1 cluster
> - assigned this property to vm in 4.1 cluster
> - i make UserDefinedVMProperties empty
> - vm in 4.1 cluster still had the property in its settings (check in DB)
> - increased cluster to 4.2
> 
> ~~~
> Error while executing action: Update of cluster compatibility version failed
> because there are VMs/Templates [jbelka-test1] with incorrect configuration.
> To fix the issue, please go to each of them, edit and press OK. If the save
> does not pass, fix the dialog validation.
> ~~~
> 
> - edit vm, save
> - increase cluster to 4.2
> 
> <same error as above>
> 
> - edit vm, change custom compat level to 4.2
> - the property disappeared in db for the vm
> - increased successfully cluster level
> 
> so, is the error above enough meaningful for users? i don't think so.

Comment 10 Jiri Belka 2017-10-20 11:29:38 UTC

ok

for meaningful message i opened additional bz - https://bugzilla.redhat.com/show_bug.cgi?id=1504673

Comment 11 Sandro Bonazzola 2017-12-20 10:54:31 UTC

This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017.

Since the problem described in this bug report should be
resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE.

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