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
Reducing severity as this behaviour is present in the code at least since 3.5 (maybe from beginning)
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.
Makes sense to me. I'll clone it.
*** Bug 1478879 has been marked as a duplicate of this bug. ***
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.
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.
ok for meaningful message i opened additional bz - https://bugzilla.redhat.com/show_bug.cgi?id=1504673
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.