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

Bug 1279417

Summary:	[text] - Although DC upgrade fails, in audit logs it seems the DC was updated
Product:	[oVirt] ovirt-engine	Reporter:	Aharon Canan <acanan>
Component:	General	Assignee:	Benny Zlotnik <bzlotnik>
Status:	CLOSED NOTABUG	QA Contact:	Raz Tamir <ratamir>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.5.6	CC:	acanan, amureini, bugs, gklein, laravot, sbonazzo, tnisan, ylavi
Target Milestone:	ovirt-4.1.2	Keywords:	EasyFix
Target Release:	---	Flags:	rule-engine: ovirt-4.1+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-04-03 11:25:41 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Storage	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Aharon Canan 2015-11-09 12:30:00 UTC

Description of problem:
Although DC upgrade fails, in audit logs it seems the DC was updated (where it didn't)
(Extra info on bug 1269471)

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

How reproducible:
100%

Steps to Reproduce:
===================
1. Created A 3.4 DC with one host and 2 domains (ISCSI and NFS).
2. Moved host to maintenance
3. Blocked connection to the non master domain (NFS)
4. Activated the host
5. The host became SPM
6. Attempt to upgrade the DC to 3.5

Results (From audit)-
=====================
2015-Nov-08, 18:28 Data Center DC was updated by admin@internal
2015-Nov-08, 18:28 Data Center DC has encountered problems during upgrade process.

Expected results:
==================
The audit log should be fixed though so it doesn't mislead the user. Probably something like:

- Started DC Upgrade for DC xyz
- DC Upgrade for DC xyz failed/succeeded.

Additional info:

Comment 1 Red Hat Bugzilla Rules Engine 2015-11-10 06:11:39 UTC

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 2 Sandro Bonazzola 2016-02-23 09:13:14 UTC

Not blocking bug #1285700 (upgrade to 3.6) since this has been targeted to 4.0

Comment 3 Yaniv Lavi 2017-02-23 11:24:03 UTC

Moving out all non blocker\exceptions.

Comment 4 Liron Aravot 2017-03-01 17:15:33 UTC

The audit log reflects what actually happens - the DC info was indeed updated in the database, but the upgra*d*e on the storage failed.
I'd leave the audit logs as they are for now, we need to revisit the flow itself  (as now even when the upgrade fails we can't determine what actually happened).

Tal, should we change the target for this bug and use it? or close it and have another RFE to inspect that flow?

Comment 5 Tal Nisan 2017-03-02 07:22:48 UTC

Better to have a separate bug for the flow itself, this bug is for the audit log issue, can we add an audit log about the upgrade failing the storage?

Comment 6 Liron Aravot 2017-03-23 15:50:40 UTC

(In reply to Tal Nisan from comment #5)
> Better to have a separate bug for the flow itself, this bug is for the audit
> log issue, can we add an audit log about the upgrade failing the storage?

Thanks Tal,
we have an audit log - that's what will be printed right now (see below). We can look into a way of improving it.

2015-Nov-08, 18:28 Data Center DC was updated by admin@internal
2015-Nov-08, 18:28 Data Center DC has encountered problems during upgrade process.

Comment 7 Tal Nisan 2017-03-28 08:46:21 UTC

Why not change it to "Starting data center upgrade on..." as Aharon suggested?

Comment 8 Liron Aravot 2017-03-30 08:08:19 UTC

The current audit logs we have are (quoted from the initial bug)

2015-Nov-08, 18:28 Data Center DC was updated by admin@internal
2015-Nov-08, 18:28 Data Center DC has encountered problems during upgrade process.

The first one indicates that the db upgrade of the datacenter occured.

The second one indicates on failure to perform the storage upgrade.
The upgrade vdsm verb updates the master domain in it's syncornous execution and starts upgrade threads for the rest of the pool domains.
As we can't tell when the upgrade in the storage side will end, having a "Starting.." audit log seems like a bit less clear to me (as we won't have an "Ended.." audit log).